匹配

MATCH

该MATCH子句是大多数 Cypher 查询的核心。这是示例部分。使用 ASCII 字符表示节点和关系，我们绘制我们感兴趣的数据。我们用括号绘制节点，用大于号或小于号（-->和<--）的破折号对绘制关系。<和>符号表示关系方向。在用方括号分隔并以冒号为前缀的破折号之间，我们放置关系名称。节点标签同样以冒号为前缀。然后在花括号内指定节点（和关系）属性键值对（非常类似于 Javascript 对象）。

The MATCH clause is at the heart of most Cypher queries. This is the specification by example part. Using ASCII characters to represent nodes and relationships, we draw the data we’re interested in. We draw nodes with parentheses, and relationships using pairs of dashes with greater-than or less-than signs (--> and <--). The < and > signs indicate relationship direction. Between the dashes, set off by square brackets and prefixed by a colon, we put the relationship name. Node labels are similarly prefixed by a colon. Node (and relationship) property key-value pairs are then specified within curly braces (much like a Javascript object).

在我们的示例查询中，我们正在寻找一个Person带有属性标签的节点，name该属性的值为Jim。此查找的返回值与标识符 绑定a。此标识符允许我们在查询的其余部分引用代表 Jim 的节点。

In our example query, we’re looking for a node labeled Person with a name property whose value is Jim. The return value from this lookup is bound to the identifier a. This identifier allows us to refer to the node that represents Jim throughout the rest of the query.

此起始节点是简单模式的一部分(a)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)，该模式描述了一条由三个节点组成的路径，其中一个节点我们已绑定到标识符a，其他节点已绑定到b和c。这些节点通过多种关系连接，如图3-1KNOWS所示。

This start node is part of a simple pattern (a)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c) that describes a path comprising three nodes, one of which we’ve bound to the identifier a, the others to b and c. These nodes are connected by way of several KNOWS relationships, as per Figure 3-1.

从理论上讲，这种模式可能在我们的图形数据中出现多次；对于大型用户集，可能存在许多与此模式相对应的相互关系。为了本地化查询，我们需要将其某些部分锚定到图形中的一个或多个位置。在指定我们正在寻找标记为Person其name属性值为 的节点时Jim，我们将模式绑定到图形中的特定节点 - 代表 Jim 的节点。然后，Cypher 将模式的其余部分与紧邻此锚点的图形进行匹配。在此过程中，它会发现要绑定到其他标识符的节点。虽然a将始终锚定到 Jim，b并且c将在查询执行时绑定到一系列节点。

This pattern could, in theory, occur many times throughout our graph data; with a large user set, there may be many mutual relationships corresponding to this pattern. To localize the query, we need to anchor some part of it to one or more places in the graph. In specifying that we’re looking for a node labeled Person whose name property value is Jim, we’ve bound the pattern to a specific node in the graph — the node representing Jim. Cypher then matches the remainder of the pattern to the graph immediately surrounding this anchor point. As it does so, it discovers nodes to bind to the other identifiers. While a will always be anchored to Jim, b and c will be bound to a sequence of nodes as the query executes.

或者，我们可以将锚定表达为子句中的谓语WHERE。

Alternatively, we can express the anchoring as a predicate in the WHERE clause.

MATCH (a:Person)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)
WHERE a.name = 'Jim'
RETURN b, c

MATCH (a:Person)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)
WHERE a.name = 'Jim'
RETURN b, c

这里我们将属性查找从子句移到MATCH了WHERE子句。结果与我们之前的查询相同。

Here we’ve moved the property lookup from the MATCH clause to the WHERE clause. The outcome is the same as our earlier query.

返回

RETURN

此子句指定应将匹配数据中的哪些节点、关系和属性返回给客户端。在我们的示例查询中，我们感兴趣的是返回与b和c标识符绑定的节点。当客户端迭代结果时，每个匹配节点都会延迟绑定到其标识符。

This clause specifies which nodes, relationships, and properties in the matched data should be returned to the client. In our example query, we’re interested in returning the nodes bound to the b and c identifiers. Each matching node is lazily bound to its identifier as the client iterates the results.

其他密码条款

Other Cypher Clauses

我们可以在 Cypher 查询中使用的其他子句包括：

The other clauses we can use in a Cypher query include:

提供过滤模式匹配结果的标准。

Provides criteria for filtering pattern matching results.

创造节点和关系。

Create nodes and relationships.

确保通过重用与提供的谓词匹配的现有节点和关系，或者通过创建新的节点和关系，来确保提供的模式存在于图中。

Ensures that the supplied pattern exists in the graph, either by reusing existing nodes and relationships that match the supplied predicates, or by creating new nodes and relationships.

移除节点、关系和属性。

Removes nodes, relationships, and properties.

套财产价值。

Sets property values.

表演列表中每个元素的更新操作。

Performs an updating action for each element in a list.

合并来自两个或多个查询的结果。

Merges results from two or more queries.

链条后续查询部分并将结果从一个部分转发到下一个部分。类似于 Unix 中的管道命令。

Chains subsequent query parts and forwards results from one to the next. Similar to piping commands in Unix.

指定图中一个或多个明确的起点（节点或关系）。 （START已弃用，改为在MATCH子句中指定锚点。）

Specifies one or more explicit starting points — nodes or relationships — in the graph. (START is deprecated in favor of specifying anchor points in a MATCH clause.)

如果这些子句看起来很熟悉——尤其是如果你是 SQL 开发人员——那就太好了！Cypher 旨在让你足够熟悉，以帮助你快速完成学习曲线。同时，它又足够不同，强调我们处理的是图，而不是关系集。

If these clauses look familiar — especially if you’re a SQL developer — that’s great! Cypher is intended to be familiar enough to help you move rapidly along the learning curve. At the same time, it’s different enough to emphasize that we’re dealing with graphs, not relational sets.

在本章后面，我们将看到这些条款的一些例子。当它们出现时，我们将更详细地描述它们如何工作。

We’ll see some examples of these clauses later in the chapter. Where they occur, we’ll describe in more detail how they work.

现在我们已经了解了如何使用 Cypher 描述和查询图形，我们可以看一些图形建模的示例。

Now that we’ve seen how we can describe and query a graph using Cypher, we can look at some examples of graph modeling.

系统管理领域中的关系建模

Relational Modeling in a Systems Management Domain

关系世界中建模的初始阶段与许多其他数据建模技术的第一阶段类似：即我们寻求理解并就领域中的实体、它们如何相互关联以及控制它们的状态转换的规则达成一致。大部分工作往往以非正式的方式进行，通常是通过白板草图和主题专家与系统和数据架构师之间的讨论。为了表达我们的共同理解和一致意见，我们通常会创建一个图表，如图3-2所示，这是一个图形。

The initial stage of modeling in the relational world is similar to the first stage of many other data modeling techniques: that is, we seek to understand and agree on the entities in the domain, how they interrelate, and the rules that govern their state transitions. Most of this tends to be done informally, often through whiteboard sketches and discussions between subject matter experts and systems and data architects. To express our common understanding and agreement, we typically create a diagram such as the one in Figure 3-2, which is a graph.

下一阶段将以更严格的形式（如实体关系 (ER) 图）捕获此一致性 — 另一个图。使用更严格的符号将概念模型转换为逻辑模型，这为我们提供了第二次机会来完善我们的领域词汇表，以便与关系数据库专家共享。（这种方法并非总是必要的：熟练的关系用户通常会直接转到表设计和规范化，而无需先描述中间 ER 图。）在我们的示例中，我们在图3-3所示的 ER 图中捕获了领域。

The next stage captures this agreement in a more rigorous form such as an entity-relationship (E-R) diagram — another graph. This transformation of the conceptual model into a logical model using a stricter notation provides us with a second chance to refine our domain vocabulary so that it can be shared with relational database specialists. (Such approaches aren’t always necessary: adept relational users often move directly to table design and normalization without first describing an intermediate E-R diagram.) In our example, we’ve captured the domain in the E-R diagram shown in Figure 3-3.

找到合适的逻辑模型后，我们将其映射到表和关系中，并对其进行规范化以消除数据冗余。在许多情况下，这一步骤可以简单到将 ER 图转录为表格形式，然后通过 SQL 命令将这些表加载到数据库中。但即使是最简单的情况也能凸显关系模型的特性。例如，在图 3-4中，我们看到大量意外的复杂性以外键约束（所有带注释的）的形式潜入模型中[FK]，这些约束支持一对多关系，以及连接表（例如AppDatabase），这些表支持多对多关系——所有这些都发生在我们添加一行真实用户数据之前。这些约束是模型级元数据，其存在只是为了让我们可以在查询时具体化表之间的关系。然而，这种结构化数据的存在是显而易见的，因为它使域数据变得混乱和模糊，数据服务于数据库，而不是用户。

Having arrived at a suitable logical model, we map it into tables and relations, which are normalized to eliminate data redundancy. In many cases this step can be as simple as transcribing the E-R diagram into a tabular form and then loading those tables via SQL commands into the database. But even the simplest case serves to highlight the idiosyncrasies of the relational model. For example, in Figure 3-4 we see that a great deal of accidental complexity has crept into the model in the form of foreign key constraints (everything annotated [FK]), which support one-to-many relationships, and join tables (e.g., AppDatabase), which support many-to-many relationships — and all this before we’ve added a single row of real user data. These constraints are model-level metadata that exist simply so that we can make concrete the relations between tables at query time. Yet the presence of this structural data is keenly felt, because it clutters and obscures the domain data with data that serves the database, not the user.

图 3-3数据中心域的实体关系图

我们现在有了一个相对忠实于领域的规范化模型。尽管这个模型以外键和连接表的形式充满了大量偶然复杂性，但它不包含重复数据。但我们的设计工作尚未完成。关系范式的挑战之一是，规范化模型通常不够快，无法满足实际需求。对于许多生产系统，规范化模式在理论上适合回答我们可能希望向领域提出的任何类型的临时问题，但在实践中必须进一步调整和专门化以适应特定的访问模式。换句话说，为了使关系存储足以满足常规应用程序的需求，我们必须抛弃任何真正的领域亲和力的痕迹，并接受我们必须更改用户的数据模型以适应数据库引擎而不是用户的事实。这种技术称为非规范化。

We now have a normalized model that is relatively faithful to the domain. This model, though imbued with substantial accidental complexity in the form of foreign keys and join tables, contains no duplicate data. But our design work is not yet complete. One of the challenges of the relational paradigm is that normalized models generally aren’t fast enough for real-world needs. For many production systems, a normalized schema, which in theory is fit for answering any kind of ad hoc question we may wish to pose to the domain, must in practice be further adapted and specialized for specific access patterns. In other words, to make relational stores perform well enough for regular application needs, we have to abandon any vestiges of true domain affinity and accept that we have to change the user’s data model to suit the database engine, not the user. This technique is called denormalization.

反规范化涉及复制数据（在某些情况下是大量复制）以获得查询性能。以用户及其联系方式为例。典型用户通常有多个电子邮件地址，在完全规范化的模型中，我们会将其存储在单独的EMAIL表中。但是，为了减少连接以及两个表之间连接造成的性能损失，通常会在表中内联这些数据USER，添加一个或多个列来存储用户最重要的电子邮件地址。

Denormalization involves duplicating data (substantially in some cases) in order to gain query performance. Take as an example users and their contact details. A typical user often has several email addresses, which, in a fully normalized model, we would store in a separate EMAIL table. To reduce joins and the performance penalty imposed by joining between two tables, however, it is quite common to inline this data in the USER table, adding one or more columns to store a user’s most important email addresses.

图 3-4.数据中心域的表和关系

尽管反规范化可能是一件安全的事情（假设开发人员了解反规范化模型以及它如何映射到以领域为中心的代码，并且拥有来自数据库的强大事务支持），但这通常不是一项简单的任务。为了获得最佳结果，我们通常会求助于真正的 RDBMS 专家，将我们的规范化模型转换为与底层 RDBMS 和物理存储层的特征一致的反规范化模型。在这样做时，我们接受可能存在大量的数据冗余。

Although denormalization may be a safe thing to do (assuming developers understand the denormalized model and how it maps to their domain-centric code, and have robust transactional support from the database), it is usually not a trivial task. For the best results, we usually turn to a true RDBMS expert to munge our normalized model into a denormalized one aligned with the characteristics of the underlying RDBMS and physical storage tier. In doing this, we accept that there may be substantial data redundancy.

我们可能会认为，所有这些设计-规范化-非规范化工作都是可以接受的，因为这是一次性任务。这种思想流派认为，这项工作的成本在系统的整个生命周期内分摊（包括开发和生产），因此，与项目的总成本相比，生成高性能关系模型的工作量相对较小。这是一个有吸引力的想法，但在许多情况下，它与现实不符，因为系统不仅在开发过程中发生变化，而且在生产生命周期中也会发生变化。

We might be tempted to think that all this design-normalize-denormalize effort is acceptable because it is a one-off task. This school of thought suggests that the cost of the work is amortized across the entire lifetime of the system (which includes both development and production) such that the effort of producing a performant relational model is comparatively small compared to the overall cost of the project. This is an appealing notion, but in many cases it doesn’t match reality, because systems change not only during development, but also during their production lifetimes.

数据模型变更的摊销观点认为，开发过程中昂贵的变更被生产中稳定的模型的长期利益所掩盖，这种观点假设系统大部分时间都在生产环境中，并且这些生产环境是稳定的。虽然大多数系统大部分时间都在生产环境中，但这些环境很少是稳定的。随着业务需求的变化或监管要求的发展，我们的系统及其所基于的数据结构也必须随之变化。

The amortized view of data model change, in which costly changes during development are eclipsed by the long-term benefits of a stable model in production, assumes that systems spend the majority of their time in production environments, and that these production environments are stable. Though it may be the case that most systems spend most of their time in production environments, these environments are rarely stable. As business requirements change or regulatory requirements evolve, so must our systems and the data structures on which they are built.

在项目的设计和开发阶段，数据模型不可避免地会经历大量修改，而且几乎在所有情况下，这些修改都是为了使模型适应在投入生产后会使用该模型的应用程序的需求。这些初始设计的影响是如此强大，以至于一旦投入生产，几乎不可能修改应用程序和模型以适应其最初设计时未考虑的事情。

Data models invariably undergo substantial revision during the design and development phases of a project, and in almost every case, these revisions are intended to accommodate the model to the needs of the applications that will consume it once it is in production. These initial design influences are so powerful that it becomes nearly impossible to modify the application and the model once they’re in production to accommodate things they were not originally designed to do.

技术我们将结构变化引入数据库的机制称为迁移，这种机制因Rails等应用程序开发框架而广为人知。迁移提供了一种结构化、分步式的方法，可将一组数据库重构应用于数据库，以便可以负责任地发展数据库以满足使用它的应用程序不断变化的需求。然而，与通常只需几秒钟或几分钟即可完成的代码重构不同，数据库重构可能需要数周或数月才能完成，并且架构更改会导致停机。数据库重构速度慢、风险大且成本高昂。

The technical mechanism by which we introduce structural change into a database is called migration, as popularized by application development frameworks such as Rails. Migrations provide a structured, step-wise approach to applying a set of database refactorings to a database so that it can be responsibly evolved to meet the changing needs of the applications that use it. Unlike code refactorings, however, which we typically accomplish in a matter of seconds or minutes, database refactorings can take weeks or months to complete, with downtime for schema changes. Database refactoring is slow, risky, and expensive.

那么，非规范化模型的问题在于它抵制业务对其系统所要求的那种快速发展。正如我们在数据中心示例中所看到的，在实施关系解决方案的过程中对白板模型施加的更改在概念世界和数据的物理布局方式之间造成了鸿沟；这种概念关系不协调几乎阻止了业务利益相关者积极协作以进一步发展系统。利益相关者的参与止步于关系大厦的门槛。在开发方面，将变化的业务需求转化为底层和根深蒂固的关系结构的困难导致系统的发展落后于业务的发展。如果没有专家的帮助和严格的规划，迁移非规范化数据库会带来多种风险。如果迁移无法保持存储亲和性，性能可能会受到影响。同样严重的是，如果故意复制的数据在迁移后被遗弃，我们可能会损害整个数据的完整性。

The problem, then, with the denormalized model is its resistance to the kind of rapid evolution the business demands of its systems. As we’ve seen with the data center example, the changes imposed on the whiteboard model over the course of implementing a relational solution create a gulf between the conceptual world and the way the data is physically laid out; this conceptual-relational dissonance all but prevents business stakeholders from actively collaborating in the further evolution of a system. Stakeholder participation stops at the threshold of the relational edifice. On the development side, the difficulties in translating changed business requirements into the underlying and entrenched relational structure cause the evolution of the system to lag behind the evolution of the business. Without expert assistance and rigorous planning, migrating a denormalized database poses several risks. If the migrations fail to maintain storage-affinity, performance can suffer. Just as serious, if deliberately duplicated data is left orphaned after a migration, we risk compromising the integrity of the data as a whole.

测试模型

Testing the Model

一旦我们完善了领域模型，下一步就是测试它是否适合回答实际查询。尽管图形非常适合支持不断发展的结构（因此可以纠正任何错误的早期设计决策），但有一些设计决策一旦融入我们的应用程序，就会阻碍我们进一步发展。通过在这个早期阶段审查领域模型和由此产生的图形模型，我们可以避免这些陷阱。图形结构的后续更改将完全由业务变化驱动，而不是由缓解不良设计决策的需求驱动。

Once we’ve refined our domain model, the next step is to test how suitable it is for answering realistic queries. Although graphs are great for supporting a continuously evolving structure (and therefore for correcting any erroneous earlier design decisions), there are a number of design decisions that, once they are baked into our application, can hamper us further down the line. By reviewing the domain model and the resulting graph model at this early stage, we can avoid these pitfalls. Subsequent changes to the graph structure will then be driven solely by changes in the business, rather than by the need to mitigate poor design decisions.

实际上，我们可以在这里应用两种技术。第一种也是最简单的一种就是检查图表是否读得好。我们选择一个起始节点，然后按照关系到其他节点，边走边读取每个节点的标签和每个关系的名称。这样做应该可以创建合理的句子。对于我们的数据中心示例，我们可以读出这样的句子：“由应用程序实例 1、2 和 3 组成的应用程序使用位于数据库服务器 1、2 和 3 上的数据库”，以及“服务器 3 运行 VM 31，它托管应用程序实例 3。”如果以这种方式读取图表有意义，我们可以相当有信心它忠实于领域。

In practice there are two techniques we can apply here. The first, and simplest, is just to check that the graph reads well. We pick a start node, and then follow relationships to other nodes, reading each node’s labels and each relationship’s name as we go. Doing so should create sensible sentences. For our data center example, we can read off sentences like “The App, which consists of App Instances 1, 2, and 3, uses the Database, which resides on Database Servers 1, 2 and 3,” and “Server 3 runs VM 31, which hosts App Instance 3.” If reading the graph in this way makes sense, we can be reasonably confident it is faithful to the domain.

为了进一步增强信心，我们还需要考虑我们将在图表上运行的查询。在这里，我们采用了可查询性思维设计。为了验证图表是否支持我们期望在其上运行的查询类型，我们必须描述这些查询。这要求我们了解最终用户的目标；也就是说，图表将应用于哪些用例。例如，在我们的数据中心场景中，我们的一个用例涉及最终用户报告应用程序或服务无响应。为了帮助这些用户，我们必须找出无响应的原因，然后解决它。要确定可能出了什么问题，我们需要确定用户和应用程序之间的路径上有什么，以及应用程序依赖什么来向用户提供功能。给定数据中心域的特定图形表示，如果我们可以制作一个解决此用例的 Cypher 查询，我们就可以更加确定该图满足我们域的需求。

To further increase our confidence, we also need to consider the queries we’ll run on the graph. Here we adopt a design for queryability mindset. To validate that the graph supports the kinds of queries we expect to run on it, we must describe those queries. This requires us to understand our end users’ goals; that is, the use cases to which the graph is to be applied. In our data center scenario, for example, one of our use cases involves end users reporting that an application or service is unresponsive. To help these users, we must identify the cause of the unresponsiveness and then resolve it. To determine what might have gone wrong we need to identify what’s on the path between the user and the application, and also what the application depends on to deliver functionality to the user. Given a particular graph representation of the data center domain, if we can craft a Cypher query that addresses this use case, we can be even more certain that the graph meets the needs of our domain.

继续我们的示例用例，假设我们可以从常规网络监控工具更新图表，从而为我们提供近乎实时的网络状态视图。对于大型物理网络，我们可能使用复杂事件处理 (CEP)来处理低级网络事件流，仅当 CEP 解决方案引发重大域事件时才更新图表。当用户报告问题时，我们可以将物理故障查找限制在用户和应用程序以及应用程序及其依赖项之间的有问题的网络元素上。在我们的图表中，我们可以使用以下查询找到故障设备：

Continuing with our example use case, let’s assume we can update the graph from our regular network monitoring tools, thereby providing us with a near real-time view of the state of the network. With a large physical network, we might use Complex Event Processing (CEP) to process streams of low-level network events, updating the graph only when the CEP solution raises a significant domain event. When a user reports a problem, we can limit the physical fault-finding to problematic network elements between the user and the application and the application and its dependencies. In our graph we can find the faulty equipment with the following query:

MATCH (user:User)-[*1..5]-(asset:Asset)
WHERE user.name = 'User 3' AND asset.status = 'down'
RETURN DISTINCT asset

MATCH (user:User)-[*1..5]-(asset:Asset)
WHERE user.name = 'User 3' AND asset.status = 'down'
RETURN DISTINCT asset

MATCH此处的条款描述了长度可变的路径，长度介于一到五个关系之间。关系未命名且无方向（方括号之间没有冒号或关系名称，也没有箭头来指示方向）。这使我们能够匹配以下路径：

The MATCH clause here describes a variable length path between one and five relationships long. The relationships are unnamed and undirected (there’s no colon or relationship name between the square brackets, and no arrow-tip to indicate direction). This allows us to match paths such as:

(user)-[:USER_OF]->(app)
(user)-[:USER_OF]->(app)-[:USES]->(database)
(user)-[:USER_OF]->(app)-[:USES]->(database)-[:SLAVE_OF]->(another-database)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:IN]->(rack)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:IN]->(rack)
  <-[:IN]-(load-balancer)

(user)-[:USER_OF]->(app)
(user)-[:USER_OF]->(app)-[:USES]->(database)
(user)-[:USER_OF]->(app)-[:USES]->(database)-[:SLAVE_OF]->(another-database)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:IN]->(rack)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:IN]->(rack)
  <-[:IN]-(load-balancer)

也就是说，从报告问题的用户开始，我们MATCH沿着长度为 1 到 5 的无向路径对图中的所有资产进行匹配。我们将具有status值为 的属性的资产节点添加down到结果中。如果节点没有属性status，则不会将其包含在结果中。RETURN DISTINCT asset确保无论匹配多少次，结果中都会返回唯一的资产。

That is, starting from the user who reported the problem, we MATCH against all assets in the graph along an undirected path of length 1 to 5. We add asset nodes that have a status property with a value of down to our results. If a node doesn’t have a status property, it won’t be included in the results. RETURN DISTINCT asset ensures that unique assets are returned in the results, no matter how many times they are matched.

鉴于我们的图表很容易支持这样的查询，我们有信心设计适合目的。

Given that such a query is readily supported by our graph, we gain confidence that the design is fit for purpose.

开始查询

Beginning a Query

现在我们有了图谱，我们可以开始查询了。在 Cypher 中，我们总是从图中一个或多个众所周知的起点开始查询——称为绑定MATCH节点。Cypher 使用和子句中提供的任何标签和属性谓词WHERE以及索引和约束提供的元数据来查找锚定图形模式的起点。

Now that we have a graph, we can start to query it. In Cypher we always begin our queries from one or more well-known starting points in the graph — what are called bound nodes. Cypher uses any labels and property predicates supplied in the MATCH and WHERE clauses, together with metadata supplied by indexes and constraints, to find the starting points that anchor our graph patterns.

例如，如果我们想了解有关皇家剧院演出的更多信息，我们会从皇家剧院节点开始查询，通过指定其Venue标签和name属性可以找到该节点。但是，如果我们对某人的评论更感兴趣，我们会使用该人的节点作为查询的起点，匹配User标签和name属性组合。

For instance, if we wanted to discover more about performances at the Theatre Royal, we’d start our query from the Theatre Royal node, which we find by specifying its Venue label and name property. If, however, we were more interested in a person’s reviews, we’d use that person’s node as a starting point for our query, matching on the User label and name property combination.

假设我们想要了解在纽卡斯尔皇家剧院上演的所有莎士比亚戏剧。这三个事物（一个Author名为莎士比亚的、一个Venue名为皇家剧院的、一个City名为纽卡斯尔的）为我们的新查询提供了起点：

Let’s assume we want to find out about all the Shakespeare events that have taken place in the Theatre Royal in Newcastle. These three things — an Author named Shakespeare, a Venue called Theatre Royal, and a City with the name Newcastle — provide the starting points for our new query:

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'})

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'})

此子句标识具有属性键和属性值的MATCH所有节点，并将它们绑定到标识符。 （如果此图中有许多节点怎么办？我们稍后会处理这个问题。）下一步，我们找到代表纽卡斯尔的 的节点；我们将此节点绑定到标识符。 最后，与我们之前的莎士比亚查询一样，要找到莎士比亚节点本身，我们寻找具有标签和属性的节点，其值为。 我们将此查找的结果绑定到。VenuenameTheatre RoyaltheaterTheatre RoyalCitynewcastleAuthorlastnameShakespearebard

This MATCH clause identifies all Venue nodes with a property key name and property value Theatre Royal and binds them to the identifier theater. (What if there are many Theatre Royal nodes in this graph? We’ll deal with that shortly.) As the next step, we find the node representing the City of Newcastle; we bind this node to the identifier newcastle. Finally, as with our earlier Shakespeare query, to find the Shakespeare node itself, we look for a node with the label Author and a lastname property whose value is Shakespeare. We bind the result of this lookup to bard.

从现在开始，在我们的查询中，无论我们在模式中使用标识符theater、newcastle和bard，该模式都将锚定到与这三个标识符相关联的实际节点。实际上，此信息将查询绑定到图的特定部分，为我们提供了起点，以便从中匹配直接周围的节点和关系中的模式。

From now on in our query, wherever we use the identifiers theater, newcastle, and bard in a pattern, that pattern will be anchored to the real nodes associated with these three identifiers. In effect, this information binds the query to a specific part of the graph, giving us starting points from which to match patterns in the immediately surrounding nodes and relationships.

声明要查找的信息模式

Declaring Information Patterns to Find

Cypher 中的子句MATCH是魔法发生的地方。该CREATE子句试图使用 ASCII 艺术来描述图形的期望状态，并试图传达意图，因此该MATCH子句使用相同的语法来描述要在数据库中发现的模式。我们已经看过一个非常简单的MATCH子句；现在我们将看一个更复杂的模式，它可以找到纽卡斯尔皇家剧院的所有莎士比亚表演：

The MATCH clause in Cypher is where the magic happens. As much as the CREATE clause tries to convey intent using ASCII art to describe the desired state of the graph, so the MATCH clause uses the same syntax to describe patterns to discover in the database. We’ve already looked at a very simple MATCH clause; now we’ll look at a more complex pattern that finds all the Shakespeare performances at Newcastle’s Theatre Royal:

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'}),
      (newcastle)<-[:STREET|CITY*1..2]-(theater)
        <-[:VENUE]-()-[:PERFORMANCE_OF]->()
        -[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY]-(bard)
RETURN DISTINCT play.title AS play

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'}),
      (newcastle)<-[:STREET|CITY*1..2]-(theater)
        <-[:VENUE]-()-[:PERFORMANCE_OF]->()
        -[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY]-(bard)
RETURN DISTINCT play.title AS play

此MATCH模式使用了我们尚未遇到的几个句法元素。除了我们之前讨论过的锚定节点外，它还使用了模式节点、任意深度路径和匿名节点。让我们依次看一下这些元素：

This MATCH pattern uses several syntactic elements we’ve not yet come across. As well as anchored nodes that we discussed earlier, it uses pattern nodes, arbitrary depth paths, and anonymous nodes. Let’s take a look at each of these in turn:

• 标识符newcastle、theater和bard根据指定的标签和属性值锚定到图中的真实节点。
• The identifiers newcastle, theater, and bard are anchored to real nodes in the graph based on the specified label and property values.
• 如果我们的数据库中有几座皇家剧院（例如，英国城市普利茅斯、巴斯、温彻斯特和诺里奇都有一座皇家剧院），那么theater将被绑定到所有这些节点。为了将我们的模式限制在纽卡斯尔的皇家剧院，我们使用语法<-[:STREET|CITY*1..2]-，这意味着theater节点与代表泰恩河畔纽卡斯尔市的节点之间的距离不能超过两个传出STREET和/或CITY关系。通过提供可变深度路径，我们允许相对细粒度的地址层次结构（例如，包括街道、区或自治市镇和城市）。
• If there are several Theatre Royals in our database (the British cities of Plymouth, Bath, Winchester, and Norwich all have a Theatre Royal, for example), then theater will be bound to all these nodes. To restrict our pattern to the Theatre Royal in Newcastle, we use the syntax <-[:STREET|CITY*1..2]-, which means the theater node can be no more than two outgoing STREET and/or CITY relationships away from the node representing the city of Newcastle-upon-Tyne. By providing a variable depth path, we allow for relatively fine-grained address hierarchies (comprising, for example, street, district or borough, and city).
• 该语法(theater)<-[:VENUE]-()使用匿名节点，因此括号中为空。我们了解数据，因此我们期望匿名节点与表演相匹配，但由于我们不想在查询或结果中的其他地方使用个别表演的详细信息，因此我们不命名节点或将其绑定到标识符。
• The syntax (theater)<-[:VENUE]-() uses the anonymous node, hence the empty parentheses. Knowing the data as we do, we expect the anonymous node to match performances, but because we’re not interested in using the details of individual performances elsewhere in the query or in the results, we don’t name the node or bind it to an identifier.
• 我们再次使用匿名节点将演出与制作联系起来（()-[:PERFORMANCE_OF]->()）。如果我们有兴趣返回演出和制作的详细信息，我们会用标识符替换这些匿名节点的出现：(performance)-[:PERFORMANCE_OF]->(production)。
• We use the anonymous node again to link the performance to the production (()-[:PERFORMANCE_OF]->()). If we were interested in returning details of performances and productions, we would replace these occurrences of the anonymous node with identifiers: (performance)-[:PERFORMANCE_OF]->(production).
• 的其余部分MATCH是一个简单的(play)<-[:WROTE_PLAY]-(bard)节点到关系到节点模式匹配。此模式确保我们只返回莎士比亚写的剧本。由于(play)连接到匿名制作节点，并通过连接到表演节点，我们可以安全地推断它已在纽卡斯尔皇家剧院上演。在命名剧本节点时，我们将其纳入范围，以便我们可以稍后在查询中使用它。
• The remainder of the MATCH is a straightforward (play)<-[:WROTE_PLAY]-(bard) node-to-relationship-to-node pattern match. This pattern ensures that we only return plays written by Shakespeare. Because (play) is joined to the anonymous production node, and by way of that to the performance node, we can safely infer that it has been performed in Newcastle’s Theatre Royal. In naming the play node we bring it into scope so that we can use it later in the query.

运行此查询将返回在纽卡斯尔皇家剧院上演的所有莎士比亚戏剧：

Running this query returns all the Shakespeare plays that have been performed at the Theatre Royal in Newcastle:

+-----------------+
| 播放 |
+-----------------+
| “凯撒大帝”
| “暴风雨” |
+-----------------+
2 行

+-----------------+
| play            |
+-----------------+
| "Julius Caesar" |
| "The Tempest"   |
+-----------------+
2 rows

如果我们对皇家剧院的莎士比亚的整个历史感兴趣，那么这很好，但如果我们只对特定的戏剧、作品或表演感兴趣，我们需要以某种方式限制结果集。

This is great if we’re interested in the entire history of Shakespeare at the Theatre Royal, but if we’re interested only in specific plays, productions, or performances, we need somehow to constrain the set of results.

限制匹配

Constraining Matches

我们使用子句约束图匹配WHERE。WHERE允许我们通过规定以下一项或多项来从结果中消除匹配的子图：

We constrain graph matches using the WHERE clause. WHERE allows us to eliminate matched subgraphs from the results by stipulating one or more of the following:

• 匹配的子图中必须存在（或不存在）某些路径。
• That certain paths must be present (or absent) in the matched subgraphs.
• 该节点必须具有某些标签或与某些名称有关系。
• That nodes must have certain labels or relationships with certain names.
• 匹配节点和关系上的特定属性必须存在（或不存在），无论其值如何。
• That specific properties on matched nodes and relationships must be present (or absent), irrespective of their values.
• 匹配节点和关系上的某些属性必须具有特定值。
• That certain properties on matched nodes and relationships must have specific values.
• 必须满足其他条件（例如，履行必须在某个日期或之前发生）。
• That other predicates must be satisfied (e.g., that performances must have occurred on or before a certain date).

相比该MATCH子句描述了结构关系并为模式的各个部分分配标识符，WHERE限制了当前的模式匹配。例如，让我们想象一下，我们想要将结果中的戏剧范围限制为莎士比亚最后时期的戏剧，该时期通常被认为是 1608 年左右开始的。我们通过过滤year匹配WROTE_PLAY关系的属性来实现这一点。为了启用此过滤，我们调整了该MATCH子句，将WROTE_PLAY关系绑定到一个标识符，我们将其称为w（关系标识符位于关系名称前缀的冒号之前）。我们然后添加一个WHERE子句来过滤此关系的year属性：

Compared to the MATCH clause, which describes structural relationships and assigns identifiers to parts of the pattern, WHERE constrains the current pattern match. Let’s imagine, for example, that we want to restrict the range of plays in our results to those from Shakespeare’s final period, which is generally accepted to have begun around 1608. We do this by filtering on the year property of matched WROTE_PLAY relationships. To enable this filtering, we adjust the MATCH clause, binding the WROTE_PLAY relationship to an identifier, which we’ll call w (relationship identifiers come before the colon that prefixes a relationship’s name). We then add a WHERE clause that filters on this relationship’s year property:

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'}),
      (newcastle)<-[:STREET|CITY*1..2]-(theater)
        <-[:VENUE]-()-[:PERFORMANCE_OF]->()
        -[:PRODUCTION_OF]->(play)<-[w:WROTE_PLAY]-(bard)
WHERE w.year > 1608
RETURN DISTINCT play.title AS play

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'}),
      (newcastle)<-[:STREET|CITY*1..2]-(theater)
        <-[:VENUE]-()-[:PERFORMANCE_OF]->()
        -[:PRODUCTION_OF]->(play)<-[w:WROTE_PLAY]-(bard)
WHERE w.year > 1608
RETURN DISTINCT play.title AS play

添加此WHERE子句意味着，对于每个成功的匹配，数据库都会检查WROTE_PLAY莎士比亚节点与匹配剧本之间的关系是否具有year值大于 1608 的属性。关系值大于 1608WROTE_PLAY的匹配year将通过测试；然后这些剧本将包含在结果中。未通过测试的匹配将不会包含在结果中。通过添加此子句，我们确保只返回莎士比亚晚期的剧本：

Adding this WHERE clause means that for each successful match, the database checks that the WROTE_PLAY relationship between the Shakespeare node and the matched play has a year property with a value greater than 1608. Matches with a WROTE_PLAY relationship whose year value is greater than 1608 will pass the test; these plays will then be included in the results. Matches that fail the test will not be included in the results. By adding this clause, we ensure that only plays from Shakespeare’s late period are returned:

+---------------+
| 播放 |
+---------------+
| “暴风雨” |
+---------------+
1 行

+---------------+
| play          |
+---------------+
| "The Tempest" |
+---------------+
1 row

处理结果

Processing Results

密码RETURN条款允许我们在将匹配的图形数据返回给执行查询的用户（或应用程序）之前对其进行一些处理。

Cypher’s RETURN clause allows us to perform some processing on the matched graph data before returning it to the user (or the application) that executed the query.

正如我们在前面的查询中看到的，我们能做的最简单的事情就是返回我们找到的剧本：

As we’ve seen in the previous queries, the simplest thing we can do is return the plays we’ve found:

RETURN DISTINCT play.title AS play

RETURN DISTINCT play.title AS play

DISTINCT确保确保返回唯一结果。由于每部戏剧可能在同一家剧院上演多次，有时甚至在不同的制作中上演，因此我们最终可能会得到重复的戏剧标题。DISTINCT过滤掉这些。

DISTINCT ensures that we return unique results. Because each play can be performed multiple times in the same theater, sometimes in different productions, we can end up with duplicate play titles. DISTINCT filters these out.

我们可以通过多种方式丰富此结果，包括聚合、排序、过滤和限制返回的数据。例如，如果我们只对符合我们标准的播放次数count感兴趣，我们可以应用以下函数：

We can enrich this result in several ways, including aggregating, ordering, filtering, and limiting the returned data. For example, if we’re only interested in the number of plays that match our criteria, we apply the count function:

RETURN count(play)

RETURN count(play)

如果我们想根据演出场次对戏剧进行排名，我们首先需要将子句PERFORMANCE_OF中的关系绑定MATCH到一个名为的标识符，p然后我们可以对其count进行和排序：

If we want to rank the plays by the number of performances, we’ll need first to bind the PERFORMANCE_OF relationship in the MATCH clause to an identifier, called p, which we can then count and order:

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'}),
      (newcastle)<-[:STREET|CITY*1..2]-(theater)
        <-[:VENUE]-()-[p:PERFORMANCE_OF]->()
        -[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY]-(bard)
RETURN   play.title AS play, count(p) AS performance_count
ORDER BY performance_count DESC

MATCH (theater:Venue {name:'Theatre Royal'}),
      (newcastle:City {name:'Newcastle'}),
      (bard:Author {lastname:'Shakespeare'}),
      (newcastle)<-[:STREET|CITY*1..2]-(theater)
        <-[:VENUE]-()-[p:PERFORMANCE_OF]->()
        -[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY]-(bard)
RETURN   play.title AS play, count(p) AS performance_count
ORDER BY performance_count DESC

此处的子句使用标识符（与子句中的关系绑定）RETURN计算关系数，并将结果别名为。然后，它根据 对结果进行排序，最常播放的剧目列在最前面：PERFORMANCE_OFpPERFORMANCE_OFMATCHperformance_countperformance_count

The RETURN clause here counts the number of PERFORMANCE_OF relationships using the identifier p (which is bound to the PERFORMANCE_OF relationships in the MATCH clause) and aliases the result as performance_count. It then orders the results based on performance_count, with the most frequently performed play listed first:

+------------------------------------------------+
| 播放 | performance_count |
+------------------------------------------------+
| “凯撒大帝” | 2 |
| 《暴风雨》 | 1 |
+------------------------------------------------+
2 行

+-------------------------------------+
| play            | performance_count |
+-------------------------------------+
| "Julius Caesar" | 2                 |
| "The Tempest"   | 1                 |
+-------------------------------------+
2 rows

查询链

Query Chaining

在我们结束对 Cypher 的简短介绍之前，还有一个有用的功能需要了解——子句WITH。有时用一个 来完成所有事情是不切实际的（或不可能的）MATCH。该WITH子句允许我们将多个匹配项链接在一起，并将前一个查询部分的结果传输到下一个查询部分。在下面的例子中，我们找到莎士比亚写的剧本，并根据它们的写作年份对它们进行排序，最新的排在最前面。WITH然后使用 ，我们将结果传输到RETURN子句，该子句使用该collect函数生成以逗号分隔的剧本标题列表：

Before we leave our brief tour of Cypher, there is one more feature that is useful to know about — the WITH clause. Sometimes it’s just not practical (or possible) to do everything you want in a single MATCH. The WITH clause allows us to chain together several matches, with the results of the previous query part being piped into the next. In the following example we find the plays written by Shakespeare, and order them based on the year in which they were written, latest first. Using WITH, we then pipe the results to the RETURN clause, which uses the collect function to produce a comma-delimited list of play titles:

MATCH (bard:Author {lastname:'Shakespeare'})-[w:WROTE_PLAY]->(play)
WITH play
ORDER BY w.year DESC
RETURN collect(play.title) AS plays

MATCH (bard:Author {lastname:'Shakespeare'})-[w:WROTE_PLAY]->(play)
WITH play
ORDER BY w.year DESC
RETURN collect(play.title) AS plays

针对我们的示例图执行此查询将产生以下结果：

Executing this query against our sample graph produces the following result:

+--------------------------------+
| 戏剧 |
+--------------------------------+
| [《暴风雨》、《凯撒大帝》] |
+--------------------------------+
1 行

+---------------------------------+
| plays                           |
+---------------------------------+
| ["The Tempest","Julius Caesar"] |
+---------------------------------+
1 row

WITH可用于将只读子句与以写为中心的SET操作分开。更一般地说，WITH它允许我们将单个复杂查询分解为几个更简单的模式，从而帮助分而治之复杂查询。

WITH can be used to separate read-only clauses from write-centric SET operations. More generally, WITH helps divide and conquer complex queries by allowing us to break a single complex query into several simpler patterns.

电子邮件来源问题域

Email Provenance Problem Domain

此示例涉及电子邮件通信分析。通信模式分析是一个经典的图谱问题，它涉及查询图谱以发现主题专家、关键影响者以及传播信息的沟通渠道。然而，在这种情况下，我们不是寻找积极的榜样（以专家的形式），而是寻找流氓：即违反公司治理甚至违法的可疑电子邮件通信模式。

This example involves the analysis of email communications. Communication pattern analysis is a classic graph problem that involves interrogating the graph to discover subject matter experts, key influencers, and the communication channels through which information is propagated. On this occasion, however, instead of looking for positive role models (in the form of experts), we were searching for rogues: that is, suspicious patterns of email communication that fall foul of corporate governance — or even break the law.

第一次迭代是否合理？

A Sensible First Iteration?

在分析该域名时，我们了解到潜在犯罪者为掩盖行踪而采用的所有巧妙模式：使用密件抄送 (BCC)、使用别名 — 甚至与这些别名进行对话以模仿真实业务利益相关者之间的合法互动。基于此分析，我们制作了一个代表性图形模型，该模型似乎可以捕获所有相关实体及其活动。

In analyzing the domain we learned about all the clever patterns that potential wrong-doers adopt to cover their tracks: using blind-copying (BCC), using aliases — even conducting conversations with those aliases to mimic legitimate interactions between real business stakeholders. Based on this analysis we produced a representative graph model that seemed to capture all the relevant entities and their activities.

为了说明这个早期模型，我们将使用 CypherCREATE子句生成一些表示用户和别名的节点。我们还将生成一个关系，表明 Alice 是 Bob 的已知别名之一。（我们假设底层图形数据库正在索引这些节点，以便我们以后可以查找它们并将它们用作查询的起点。）以下是用于创建我们的第一个图形的 Cypher 查询：

To illustrate this early model, we’ll use Cypher’s CREATE clause to generate some nodes representing users and aliases. We’ll also generate a relationship that shows that Alice is one of Bob’s known aliases. (We’ll assume that the underlying graph database is indexing these nodes so that we can later look them up and use them as starting points in our queries.) Here’s the Cypher query to create our first graph:

CREATE (alice:User {username:'Alice'}),
       (bob:User {username:'Bob'}),
       (charlie:User {username:'Charlie'}),
       (davina:User {username:'Davina'}),
       (edward:User {username:'Edward'}),
       (alice)-[:ALIAS_OF]->(bob)

CREATE (alice:User {username:'Alice'}),
       (bob:User {username:'Bob'}),
       (charlie:User {username:'Charlie'}),
       (davina:User {username:'Davina'}),
       (edward:User {username:'Edward'}),
       (alice)-[:ALIAS_OF]->(bob)

通过生成的图形模型可以很容易地观察到Alice 是 Bob 的别名，如图 3-7所示。

The resulting graph model makes it easy to observe that Alice is an alias of Bob, as we see in Figure 3-7.

图 3-7.用户和别名

现在我们通过用户交换的电子邮件将他们联系在一起：

Now we join the users together through the emails they’ve exchanged:

MATCH  (bob:User {username:'Bob'}),
       (charlie:User {username:'Charlie'}),
       (davina:User {username:'Davina'}),
       (edward:User {username:'Edward'})
CREATE (bob)-[:EMAILED]->(charlie),
       (bob)-[:CC]->(davina),
       (bob)-[:BCC]->(edward)

MATCH  (bob:User {username:'Bob'}),
       (charlie:User {username:'Charlie'}),
       (davina:User {username:'Davina'}),
       (edward:User {username:'Edward'})
CREATE (bob)-[:EMAILED]->(charlie),
       (bob)-[:CC]->(davina),
       (bob)-[:BCC]->(edward)

乍一看，这看起来像是对该领域的合理忠实的表示。每个子句都可以轻松地从左到右阅读，从而通过了我们的一项非正式正确性测试。例如，我们可以从图中看到“Bob 给 Charlie 发了电子邮件”。只有当需要确定潜在的不法分子 Bob（和他的另一个自我 Alice）到底交换了什么时，该模型的局限性才会显现出来。我们可以看到 Bob 抄送或密送了一些人，但我们看不到最重要的东西：电子邮件本身。

At first sight this looks like a reasonably faithful representation of the domain. Each clause lends itself to being read comfortably left to right, thereby passing one of our informal tests for correctness. For example, we can see from the graph that “Bob emailed Charlie.” The limitations of this model only emerge when it becomes necessary to determine exactly what was exchanged by the potential miscreant Bob (and his alter ego Alice). We can see that Bob CC’d or BCC’d some people, but we can’t see the most important thing of all: the email itself.

首次建模尝试的结果是一个以 Bob 为中心的星形图。他发送电子邮件、抄送和密件抄送的行为由从 Bob 延伸到代表其邮件收件人的节点的关系表示。然而，正如我们在图 3-8中看到的那样，数据中最关键的元素，即实际的电子邮件，却不见了。

This first modeling attempt results in a star-shaped graph with Bob at the center. His actions of emailing, copying, and blind-copying are represented by relationships that extend from Bob to the nodes representing the recipients of his mail. As we see in Figure 3-8, however, the most critical element of the data, the actual email, is missing.

图 3-8.缺少电子邮件节点导致信息丢失

这个图结构是有损的，当我们提出以下查询时，这个事实就变得明显了：

This graph structure is lossy, a fact that becomes evident when we pose the following query:

MATCH (bob:User {username:'Bob'})-[e:EMAILED]->
      (charlie:User {username:'Charlie'})
RETURN e

MATCH (bob:User {username:'Bob'})-[e:EMAILED]->
      (charlie:User {username:'Charlie'})
RETURN e

此查询返回EMAILEDBob 和 Charlie 之间的关系（Bob 发送给 Charlie 的每封电子邮件可能都对应一个关系）。这告诉我们电子邮件已经交换，但没有告诉我们有关电子邮件本身的任何信息：

This query returns the EMAILED relationships between Bob and Charlie (there will likely be one for each email that Bob has sent to Charlie). This tells us that emails have been exchanged, but it tells us nothing about the emails themselves:

+----------------+
| 电子|
+----------------+
| :EMAILED[1] {} |
+----------------+
1 行

+----------------+
| e              |
+----------------+
| :EMAILED[1] {} |
+----------------+
1 row

我们可能认为可以通过向EMAILED关系添加属性来表示电子邮件的属性，从而解决这种情况，但这只是在拖延时间。即使每个EMAILED关系都附加了属性，我们仍然无法将EMAILED、CC和BCC关系关联起来；也就是说，我们无法分辨哪些电子邮件是抄送的，哪些是密送的，以及抄送给了谁。

We might think we can remedy the situation by adding properties to the EMAILED relationship to represent an email’s attributes, but that’s just playing for time. Even with properties attached to each EMAILED relationship, we would still be unable to correlate between the EMAILED, CC, and BCC relationships; that is, we would be unable to say which emails were copied versus which were blind-copied, and to whom.

事实上，我们无意中犯了一个简单的建模错误，这主要是由于英语使用不当造成的，而不是图论的缺陷。我们日常的语言使用让我们关注动词“emailed”，而不是电子邮件本身，结果我们创建了一个缺乏真正领域洞察力的模型。

The fact is we’ve unwittingly made a simple modeling mistake, caused mostly by a lax use of English rather than any shortcomings of graph theory. Our everyday use of language has led us to focus on the verb “emailed” rather than the email itself, and as a result we’ve produced a model lacking true domain insight.

在英语中，将短语“Bob 向 Charlie 发送了一封电子邮件”缩短为“Bob 给 Charlie 发了一封电子邮件”既简单又方便。在大多数情况下，名词（实际的电子邮件）的丢失并不重要，因为意图仍然很明确。但在我们的取证场景中，这些省略的陈述是有问题的。意图保持不变，但 Bob 发送的电子邮件的数量、内容和收件人的详细信息已经丢失，因为它们被折叠到关系中EMAILED，而不是被明确地建模为节点。

In English, it’s easy and convenient to shorten the phrase “Bob sent an email to Charlie” to “Bob emailed Charlie.” In most cases, that loss of a noun (the actual email) doesn’t matter because the intent is still clear. But when it comes to our forensics scenario, these elided statements are problematic. The intent remains the same, but the details of the number, contents, and recipients of the emails that Bob sent have been lost through having been folded into a relationship EMAILED, rather than being modeled explicitly as nodes in their own right.

第二次的魅力

Second Time’s the Charm

为了修复我们的有损模型，我们需要插入电子邮件节点来表示企业内部交换的真实电子邮件，并扩展我们的关系名称集以包含电子邮件支持的完整寻址字段集。现在，我们无需创建如下有损结构：

To fix our lossy model, we need to insert email nodes to represent the real emails exchanged within the business, and expand our set of relationship names to encompass the full set of addressing fields that email supports. Now instead of creating lossy structures like this:

CREATE (bob)-[:EMAILED]->(charlie)

CREATE (bob)-[:EMAILED]->(charlie)

我们将创建更详细的结构，如下所示：

we’ll instead create more detailed structures, like this:

CREATE (email_1:Email {id:'1', content:'Hi Charlie, ... Kind regards, Bob'}),
       (bob)-[:SENT]->(email_1),
       (email_1)-[:TO]->(charlie),
       (email_1)-[:CC]->(davina),
       (email_1)-[:CC]->(alice),
       (email_1)-[:BCC]->(edward)

CREATE (email_1:Email {id:'1', content:'Hi Charlie, ... Kind regards, Bob'}),
       (bob)-[:SENT]->(email_1),
       (email_1)-[:TO]->(charlie),
       (email_1)-[:CC]->(davina),
       (email_1)-[:CC]->(alice),
       (email_1)-[:BCC]->(edward)

这会产生另一个星形图结构，但这次电子邮件位于中心，如图3-9所示。

This results in another star-shaped graph structure, but this time the email is at the center, as we see in Figure 3-9.

图 3-9.基于电子邮件的星形图

当然，在实际系统中，会有更多这样的电子邮件，每封电子邮件都有自己错综复杂的交互网络供我们探索。很容易想象，随着时间的推移，CREATE随着电子邮件服务器记录交互，会执行更多语句，如下所示（为简洁起见，我们省略了锚节点）：

Of course, in a real system there will be many more of these emails, each with its own intricate web of interactions for us to explore. It’s quite easy to imagine that over time many more CREATE statements are executed as the email server logs the interactions, like so (we’ve omitted anchor nodes for brevity):

CREATE (email_1:Email {id:'1', content:'email contents'}),
       (bob)-[:SENT]->(email_1),
       (email_1)-[:TO]->(charlie),
       (email_1)-[:CC]->(davina),
       (email_1)-[:CC]->(alice),
       (email_1)-[:BCC]->(edward);

CREATE (email_2:Email {id:'2', content:'email contents'}),
       (bob)-[:SENT]->(email_2),
       (email_2)-[:TO]->(davina),
       (email_2)-[:BCC]->(edward);

CREATE (email_3:Email {id:'3', content:'email contents'}),
       (davina)-[:SENT]->(email_3),
       (email_3)-[:TO]->(bob),
       (email_3)-[:CC]->(edward);

CREATE (email_4:Email {id:'4', content:'email contents'}),
       (charlie)-[:SENT]->(email_4),
       (email_4)-[:TO]->(bob),
       (email_4)-[:TO]->(davina),
       (email_4)-[:TO]->(edward);

CREATE (email_5:Email {id:'5', content:'email contents'}),
       (davina)-[:SENT]->(email_5),
       (email_5)-[:TO]->(alice),
       (email_5)-[:BCC]->(bob),
       (email_5)-[:BCC]->(edward);

CREATE (email_1:Email {id:'1', content:'email contents'}),
       (bob)-[:SENT]->(email_1),
       (email_1)-[:TO]->(charlie),
       (email_1)-[:CC]->(davina),
       (email_1)-[:CC]->(alice),
       (email_1)-[:BCC]->(edward);

CREATE (email_2:Email {id:'2', content:'email contents'}),
       (bob)-[:SENT]->(email_2),
       (email_2)-[:TO]->(davina),
       (email_2)-[:BCC]->(edward);

CREATE (email_3:Email {id:'3', content:'email contents'}),
       (davina)-[:SENT]->(email_3),
       (email_3)-[:TO]->(bob),
       (email_3)-[:CC]->(edward);

CREATE (email_4:Email {id:'4', content:'email contents'}),
       (charlie)-[:SENT]->(email_4),
       (email_4)-[:TO]->(bob),
       (email_4)-[:TO]->(davina),
       (email_4)-[:TO]->(edward);

CREATE (email_5:Email {id:'5', content:'email contents'}),
       (davina)-[:SENT]->(email_5),
       (email_5)-[:TO]->(alice),
       (email_5)-[:BCC]->(bob),
       (email_5)-[:BCC]->(edward);

这导致了我们在图 3-10中看到的更复杂、更有趣的图表。

This leads to the more complex, and interesting, graph we see in Figure 3-10.

图 3-10电子邮件交互图

我们现在可以查询此图表来识别潜在的可疑行为：

We can now query this graph to identify potentially suspect behavior:

MATCH (bob:User {username:'Bob'})-[:SENT]->(email)-[:CC]->(alias),
      (alias)-[:ALIAS_OF]->(bob)
RETURN email.id

MATCH (bob:User {username:'Bob'})-[:SENT]->(email)-[:CC]->(alias),
      (alias)-[:ALIAS_OF]->(bob)
RETURN email.id

在这里，我们检索了 Bob 发送的所有电子邮件，这些电子邮件抄送给了他自己的一个别名。任何符合此模式的电子邮件都表明存在恶意行为。由于 Cypher 和底层图形数据库都具有图形亲和性，因此这些查询（即使在大型数据集上）也能非常快速地运行。此查询返回以下结果：

Here we retrieve all the emails that Bob has sent where he’s CC’d one of his own aliases. Any emails that match this pattern are indicative of rogue behavior. And because both Cypher and the underlying graph database have graph affinity, these queries — even over large datasets — run very quickly. This query returns the following results:

+------------------------------------------------------+
| 电子邮件 |
+-----------------------------------------------------+
| Node[6]{id:"1",content:"电子邮件内容"} |
+-----------------------------------------------------+
1 行

+------------------------------------------+
| email                                    |
+------------------------------------------+
| Node[6]{id:"1",content:"email contents"} |
+------------------------------------------+
1 row

领域演进

Evolving the Domain

与任何数据库一样，我们的图服务于一个可能随着时间的推移而发展的系统。那么当图发展时我们应该怎么做呢？我们如何知道哪里出了问题，或者说，我们如何知道有什么东西出了问题？事实上，我们无法完全避免图数据库中的迁移：它们是生活中的现实，就像任何数据存储一样。但在图数据库中，它们通常要简单得多。

As with any database, our graph serves a system that is likely to evolve over time. So what should we do when the graph evolves? How do we know what breaks, or indeed, how do we even tell that something has broken? The fact is, we can’t completely avoid migrations in a graph database: they’re a fact of life, just as with any data store. But in a graph database they’re usually a lot simpler.

在图表中，为了添加新的事实或组合，我们倾向于添加新的节点和关系，而不是更改现有的模型。使用新类型的关系添加到图中不会影响任何现有查询，并且完全安全。使用现有关系类型更改图并更改现有节点的属性（而不仅仅是属性值）可能是安全的，但我们需要运行一组有代表性的查询，以确保图在结构更改后仍然适合用途。但是，这些活动与我们在正常数据库操作期间执行的操作完全相同，因此在图形世界中，迁移实际上只是照常进行。

In a graph, to add new facts or compositions, we tend to add new nodes and relationships rather than change the model in place. Adding to the graph using new kinds of relationships will not affect any existing queries, and is completely safe. Changing the graph using existing relationship types, and changing the properties (not just the property values) of existing nodes might be safe, but we need to run a representative set of queries to maintain confidence that the graph is still fit for purpose after the structural changes. However, these activities are precisely the same kinds of actions we perform during normal database operation, so in a graph world a migration really is just business as usual.

此时，我们有一个图表，描述了谁发送和接收了电子邮件，以及电子邮件本身的内容。但当然，电子邮件的乐趣之一是收件人可以转发或回复他们收到的电子邮件。这增加了互动和知识共享，但在某些情况下会泄露关键的业务信息。由于我们正在寻找可疑的通信模式，因此我们也应该考虑转发和回复。

At this point we have a graph that describes who sent and received emails, as well as the content of the emails themselves. But of course, one of the joys of email is that recipients can forward on or reply to an email they’ve received. This increases interaction and knowledge sharing, but in some cases leaks critical business information. Since we’re looking for suspicious communication patterns, it makes sense for us to also take into account forwarding and replies.

乍一看，似乎不需要使用数据库迁移来更新我们的图以支持我们的新用例。我们可以做的最简单的添加是向图中添加FORWARDED和关系，如图 3-11REPLIED_TO所示。这样做不会影响任何预先存在的查询，因为它们没有编码来识别新的关系。

At first glance, there would appear to be no need to use database migrations to update our graph to support our new use case. The simplest additions we can make involve adding FORWARDED and REPLIED_TO relationships to the graph, as shown in Figure 3-11. Doing so won’t affect any preexisting queries because they aren’t coded to recognize the new relationships.

图 3-11。一种幼稚的、有损的方法未能认识到转发和回复的电子邮件是一等实体

然而，这种方法很快就被证明是不够的。添加FORWARDED或REPLIED关系是幼稚和有损的，就像我们最初使用关系一样EMAILED。为了说明这一点，请考虑以下CREATE陈述：

However, this approach quickly proves inadequate. Adding FORWARDED or REPLIED relationships is naive and lossy in much the same way as our original use of an EMAILED relationship. To illustrate this, consider the following CREATE statements:

...
MATCH  (email:Email {id:'1234'})
CREATE (alice)-[:REPLIED_TO]->(email)
CREATE (davina)-[:FORWARDED]->(email)-[:TO]->(charlie)

...
MATCH  (email:Email {id:'1234'})
CREATE (alice)-[:REPLIED_TO]->(email)
CREATE (davina)-[:FORWARDED]->(email)-[:TO]->(charlie)

在第一个CREATE语句中，我们试图记录 Alice 回复了某封电子邮件的事实。从左到右阅读时，该语句合乎逻辑，但其情感是有损失的 — 我们无法判断 Alice 是回复了所有收件人email还是直接回复了作者。我们只知道发送了一些回复。第二个语句从左到右阅读也很好：Davina 转发给email了 Charlie。但我们已经使用该TO关系来表明给定的电子邮件具有TO标识主要收件人的标题。TO在这里重复使用使得无法判断谁是收件人以及谁收到了电子邮件的转发版本。

In the first CREATE statement we’re trying to record the fact that Alice replied to a particular email. The statement makes logical sense when read from left to right, but the sentiment is lossy — we can’t tell whether Alice replied to all the recipients of email or directly to the author. All we know is that some reply was sent. The second statement also reads well from left to right: Davina forwarded email to Charlie. But we already use the TO relationship to indicate that a given email has a TO header identifying the primary recipients. Reusing TO here makes it impossible to tell who was a recipient and who received a forwarded version of an email.

为了解决这个问题，我们必须考虑领域的基本原理。对电子邮件的回复本身是一个新的Email，但它也是一个Reply。换句话说，回复有两个角色，在图中可以通过将两个标签Email和附加Reply到回复节点来表示。无论回复是针对原始发件人、所有收件人还是子集，都可以使用相同的熟悉的、和关系轻松建模TO，CC而BCC原始电子邮件本身可以通过关系引用REPLY_TO。以下是经过多次电子邮件操作后修改的一系列写入内容（再次，我们省略了必要的节点锚定）：

To resolve this problem, we have to consider the fundamentals of the domain. A reply to an email is itself a new Email, but it is also a Reply. In other words, the reply has two roles, which in the graph can be represented by attaching two labels, Email and Reply, to the reply node. Whether the reply is to the original sender, all recipients, or a subset can be easily modeled using the same familiar TO, CC, and BCC relationships, while the original email itself can be referenced via a REPLY_TO relationship. Here’s a revised series of writes resulting from several email actions (again, we’ve omitted the necessary anchoring of nodes):

CREATE (email_6:Email {id:'6', content:'email'}),
       (bob)-[:SENT]->(email_6),
       (email_6)-[:TO]->(charlie),
       (email_6)-[:TO]->(davina);

CREATE (reply_1:Email:Reply {id:'7', content:'response'}),
       (reply_1)-[:REPLY_TO]->(email_6),
       (davina)-[:SENT]->(reply_1),
       (reply_1)-[:TO]->(bob),
       (reply_1)-[:TO]->(charlie);

CREATE (reply_2:Email:Reply {id:'8', content:'response'}),
       (reply_2)-[:REPLY_TO]->(email_6),
       (bob)-[:SENT]->(reply_2),
       (reply_2)-[:TO]->(davina),
       (reply_2)-[:TO]->(charlie),
       (reply_2)-[:CC]->(alice);

CREATE (reply_3:Email:Reply {id:'9', content:'response'}),
       (reply_3)-[:REPLY_TO]->(reply_1),
       (charlie)-[:SENT]->(reply_3),
       (reply_3)-[:TO]->(bob),
       (reply_3)-[:TO]->(davina);

CREATE (reply_4:Email:Reply {id:'10', content:'response'}),
       (reply_4)-[:REPLY_TO]->(reply_3),
       (bob)-[:SENT]->(reply_4),
       (reply_4)-[:TO]->(charlie),
       (reply_4)-[:TO]->(davina);

CREATE (email_6:Email {id:'6', content:'email'}),
       (bob)-[:SENT]->(email_6),
       (email_6)-[:TO]->(charlie),
       (email_6)-[:TO]->(davina);

CREATE (reply_1:Email:Reply {id:'7', content:'response'}),
       (reply_1)-[:REPLY_TO]->(email_6),
       (davina)-[:SENT]->(reply_1),
       (reply_1)-[:TO]->(bob),
       (reply_1)-[:TO]->(charlie);

CREATE (reply_2:Email:Reply {id:'8', content:'response'}),
       (reply_2)-[:REPLY_TO]->(email_6),
       (bob)-[:SENT]->(reply_2),
       (reply_2)-[:TO]->(davina),
       (reply_2)-[:TO]->(charlie),
       (reply_2)-[:CC]->(alice);

CREATE (reply_3:Email:Reply {id:'9', content:'response'}),
       (reply_3)-[:REPLY_TO]->(reply_1),
       (charlie)-[:SENT]->(reply_3),
       (reply_3)-[:TO]->(bob),
       (reply_3)-[:TO]->(davina);

CREATE (reply_4:Email:Reply {id:'10', content:'response'}),
       (reply_4)-[:REPLY_TO]->(reply_3),
       (bob)-[:SENT]->(reply_4),
       (reply_4)-[:TO]->(charlie),
       (reply_4)-[:TO]->(davina);

这将创建图 3-12中的图表，其中显示了大量回复和对回复的回复。

This creates the graph in Figure 3-12, which shows numerous replies and replies-to-replies.

现在很容易看出谁回复了 Bob 的原始电子邮件。首先，找到感兴趣的电子邮件，然后匹配所有传入的REPLY_TO关系（可能有多个回复），然后从那里匹配传入的SENT关系：这会显示发件人。在 Cypher 中，这很容易表达。事实上，Cypher 可以轻松查找回复的回复，依此类推到任意深度（尽管我们在这里将其限制为深度四）：

Now it is easy to see who replied to Bob’s original email. First, locate the email of interest, then match against all incoming REPLY_TO relationships (there may be multiple replies), and from there match against incoming SENT relationships: this reveals the sender(s). In Cypher this is simple to express. In fact, Cypher makes it easy to look for replies-to-replies-to-replies, and so on to an arbitrary depth (though we limit it to depth four here):

MATCH p=(email:Email {id:'6'})<-[:REPLY_TO*1..4]-(:Reply)<-[:SENT]-(replier)
RETURN replier.username AS replier, length(p) - 1 AS depth
ORDER BY depth

MATCH p=(email:Email {id:'6'})<-[:REPLY_TO*1..4]-(:Reply)<-[:SENT]-(replier)
RETURN replier.username AS replier, length(p) - 1 AS depth
ORDER BY depth

图 3-12.高保真度的明确建模回复

在这里，我们捕获每个匹配的路径，并将其绑定到标识符p。RETURN然后在子句中，我们计算回复链的长度（为SENT关系减 1），并返回回复者的姓名以及他或她回复的深度。此查询返回以下结果：

Here we capture each matched path, binding it to the identifier p. In the RETURN clause we then calculate the length of the reply-to chain (subtracting 1 for the SENT relationship), and return the replier’s name and the depth at which he or she replied. This query returns the following results:

+-------------------+
| 回复者 | 深度 |
+-------------------+
| “达维娜” | 1 |
| “鲍勃” | 1 |
| “查理” | 2 |
| “鲍勃” | 3 |
+-------------------+
4 行

+-------------------+
| replier   | depth |
+-------------------+
| "Davina"  | 1     |
| "Bob"     | 1     |
| "Charlie" | 2     |
| "Bob"     | 3     |
+-------------------+
4 rows

我们看到 Davina 和 Bob 都直接回复了 Bob 的原始电子邮件；Charlie 回复了其中一条回复；然后 Bob 又回复了一条回复的回复。

We see that both Davina and Bob replied directly to Bob’s original email; that Charlie replied to one of the replies; and that Bob then replied to one of the replies to a reply.

转发的电子邮件也有类似的模式，转发的电子邮件可以看作是一封新电子邮件，只是恰好包含原始电子邮件的部分文本。与回复情况一样，我们明确地对新电子邮件进行建模。我们还从转发的邮件中引用原始电子邮件，以便我们始终拥有详细而准确的出处数据。如果转发的邮件本身被转发，情况也是如此，依此类推。例如，如果 Alice（Bob 的另一个自我）给 Bob 发送电子邮件，试图建立单独的具体身份，然后 Bob（希望进行一些诡计）将该电子邮件转发给 Charlie，然后 Charlie 将其转发给 Davina，我们实际上有三封电子邮件需要考虑。假设用户（及其别名）已经在数据库中，在 Cypher 中，我们会将该审计信息写入数据库，如下所示：

It’s a similar pattern for a forwarded email, which can be regarded as a new email that simply happens to contain some of the text of the original email. As with the reply case, we model the new email explicitly. We also reference the original email from the forwarded mail so that we always have detailed and accurate provenance data. The same applies if the forwarded mail is itself forwarded, and so on. For example, if Alice (Bob’s alter ego) emails Bob to try to establish separate concrete identities, and then Bob (wishing to perform some subterfuge) forwards that email on to Charlie, who then forwards it onto Davina, we actually have three emails to consider. Assuming the users (and their aliases) are already in the database, in Cypher we’d write that audit information into the database as follows:

CREATE (email_11:Email {id:'11', content:'email'}),
       (alice)-[:SENT]->(email_11)-[:TO]->(bob);

CREATE (email_12:Email:Forward {id:'12', content:'email'}),
       (email_12)-[:FORWARD_OF]->(email_11),
       (bob)-[:SENT]->(email_12)-[:TO]->(charlie);

CREATE (email_13:Email:Forward {id:'13', content:'email'}),
       (email_13)-[:FORWARD_OF]->(email_12),
       (charlie)-[:SENT]->(email_13)-[:TO]->(davina);

CREATE (email_11:Email {id:'11', content:'email'}),
       (alice)-[:SENT]->(email_11)-[:TO]->(bob);

CREATE (email_12:Email:Forward {id:'12', content:'email'}),
       (email_12)-[:FORWARD_OF]->(email_11),
       (bob)-[:SENT]->(email_12)-[:TO]->(charlie);

CREATE (email_13:Email:Forward {id:'13', content:'email'}),
       (email_13)-[:FORWARD_OF]->(email_12),
       (charlie)-[:SENT]->(email_13)-[:TO]->(davina);

完成这些写入后，我们的数据库将包含图 3-13所示的子图。

On completion of these writes, our database will contain the subgraph shown in Figure 3-13.

图 3-13.明确建模电子邮件转发

利用该图表，我们可以确定转发的电子邮件链的各种路径。

Using this graph, we can determine the various paths of a forwarded email chain.

MATCH (email:Email {id:'11'})<-[f:FORWARD_OF*]-(:Forward)
RETURN count(f)

MATCH (email:Email {id:'11'})<-[f:FORWARD_OF*]-(:Forward)
RETURN count(f)

FORWARD_OF此查询从给定的电子邮件开始，然后与转发电子邮件树中的所有传入关系进行匹配，深度不限。这些关系与标识符绑定f。要计算电子邮件被转发的次数，我们使用 Cypher函数计算FORWARD_OF绑定到的关系数。在此示例中，我们看到原始电子邮件已被fcount转发两次：

This query starts at the given email and then matches against all incoming FORWARD_OF relationships in the tree of forwarded emails to any depth. These relationships are bound to an identifier f. To calculate the number of times the email has been forwarded, we count the number of FORWARD_OF relationships bound to f using Cypher’s count function. In this example, we see the original email has been forwarded twice:

+----------+
| 计数(f) |
+----------+
| 2 |
+----------+
1 行

+----------+
| count(f) |
+----------+
| 2        |
+----------+
1 row

节点代表事物，关系代表结构

Nodes for Things, Relationships for Structure

虽然并非适用于每种情况，但这些一般准则将帮助我们选择何时使用节点，何时使用关系：

Though not applicable in every situation, these general guidelines will help us choose when to use nodes, and when to use relationships:

• 使用节点来表示实体——即我们领域中我们感兴趣的 事物，并且可以被标记和分组。
• Use nodes to represent entities — that is, the things in our domain that are of interest to us, and which can be labeled and grouped.
• 使用关系来表达实体之间的联系并为每个实体建立语义上下文，从而构建领域。
• Use relationships both to express the connections between entities and to establish semantic context for each entity, thereby structuring the domain.
• 使用关系方向进一步明确关系语义。许多关系是不对称的，这就是为什么属性图中的关系总是有向的。对于双向关系，我们应该让查询忽略方向，而不是使用两个关系。
• Use relationship direction to further clarify relationship semantics. Many relationships are asymmetrical, which is why relationships in a property graph are always directed. For bidirectional relationships, we should make our queries ignore direction, rather than using two relationships.
• 使用节点属性来表示实体属性，以及任何必要的实体元数据，例如时间戳、版本号等。
• Use node properties to represent entity attributes, plus any necessary entity metadata, such as timestamps, version numbers, etc.
• 使用关系属性来表达关系的强度、权重或质量，以及任何必要的关系元数据，例如时间戳、版本号等。
• Use relationship properties to express the strength, weight, or quality of a relationship, plus any necessary relationship metadata, such as timestamps, version numbers, etc.

勤于发现和捕获领域实体是有好处的。正如我们在第 3 章中看到的那样，使用随意命名的关系来建模那些实际上应该表示为节点的东西相对容易。如果我们想使用关系来建模实体（例如电子邮件或评论），我们必须确保该实体不能与两个以上的其他实体相关。请记住，关系必须有一个起始节点和一个终止节点，不多也不少。如果我们后来发现需要将我们建模为关系的东西连接到两个以上的其他实体，我们就必须将关系中的实体重构为一个单独的节点。这对数据模型来说是一个重大更改，可能会要求我们更改生成或使用数据的任何查询和应用程序代码。

It pays to be diligent about discovering and capturing domain entities. As we saw in Chapter 3, it’s relatively easy to model things that really ought to be represented as nodes using carelessly named relationships instead. If we’re tempted to use a relationship to model an entity — an email, or a review, for example — we must make certain that this entity cannot be related to more than two other entities. Remember, a relationship must have a start node and an end node — nothing more, nothing less. If we find later that we need to connect something we’ve modeled as a relationship to more than two other entities, we’ll have to refactor the entity inside the relationship out into a separate node. This is a breaking change to the data model, and will likely require us to make changes to any queries and application code that produce or consume the data.

细粒度关系与通用关系

Fine-Grained versus Generic Relationships

在设计关系时，我们应注意使用细粒度关系名称与使用属性限定的通用关系之间的权衡。这是使用DELIVERY_ADDRESS和HOME_ADDRESS与ADDRESS {type:'delivery'}和之间的区别ADDRESS {type:'home'}。

When designing relationships we should be mindful of the trade-offs between using fine-grained relationship names versus generic relationships qualified with properties. It’s the difference between using DELIVERY_ADDRESS and HOME_ADDRESS versus ADDRESS {type:'delivery'} and ADDRESS {type:'home'}.

关系是进入图谱的必经之路。通过关系名称进行区分是从遍历中消除图谱大片的最佳方法。使用一个或多个属性值来决定是否遵循关系会在第一次访问这些属性时产生额外的 I/O，因为这些属性位于与关系不同的存储文件中（但此后，它们会被缓存）。

Relationships are the royal road into the graph. Differentiating by relationship name is the best way of eliminating large swathes of the graph from a traversal. Using one or more property values to decide whether or not to follow a relationship incurs extra I/O the first time those properties are accessed because the properties reside in a separate store file from the relationships (after that, however, they’re cached).

每当我们有一组封闭的关系名称时，我们就会使用细粒度关系。权重（最短加权路径算法所要求的）很少包含一个封闭集，通常最好以关系上的属性来表示。

We use fine-grained relationships whenever we have a closed set of relationship names. Weightings — as required by a shortest-weighted-path algorithm — rarely comprise a closed set, and are usually best represented as properties on relationships.

然而，有时我们有一组封闭的关系，但是在某些遍历中我们希望遵循该集合内特定类型的关系，而在其他遍历中我们希望遵循所有关系，而不管类型如何。地址就是一个很好的例子。遵循封闭集原则，我们可以选择创建HOME_ADDRESS、WORK_ADDRESS和DELIVERY_ADDRESS关系。这使我们能够遵循特定类型的地址关系（DELIVERY_ADDRESS例如）而忽略所有其余关系。但是，如果我们想找到用户的所有地址，我们该怎么做？这里有几个选择。首先，我们可以在查询中编码所有不同关系类型的知识：例如MATCH (user)-[:HOME_ADDRESS|WORK_ADDRESS|DELIVERY_ADDRESS]->(address)。但是，当存在许多不同类型的关系时，这很快就会变得难以处理。或者，ADDRESS除了细粒度关系之外，我们还可以向我们的模型添加更通用的关系。然后，每个表示地址的节点都使用两种关系连接到用户：细粒度关系（例如DELIVERY_ADDRESS）和更通用的ADDRESS {type:'delivery'}关系。

Sometimes, however, we have a closed set of relationships, but in some traversals we want to follow specific kinds of relationships within that set, whereas in others we want to follow all of them, irrespective of type. Addresses are a good example. Following the closed-set principle, we might choose to create HOME_ADDRESS, WORK_ADDRESS, and DELIVERY_ADDRESS relationships. This allows us to follow specific kinds of address relationships (DELIVERY_ADDRESS, for example) while ignoring all the rest. But what do we do if we want to find all addresses for a user? There are a couple of options here. First, we can encode knowledge of all the different relationship types in our queries: e.g., MATCH (user)-[:HOME_ADDRESS|WORK_ADDRESS|DELIVERY_ADDRESS]->(address). This, however, quickly becomes unwieldy when there are lots of different kinds of relationships. Alternatively, we can add a more generic ADDRESS relationship to our model, in addition to the fine-grained relationships. Every node representing an address is then connected to a user using two relationships: a fined-grained relationship (e.g., DELIVERY_ADDRESS) and the more generic ADDRESS {type:'delivery'} relationship.

正如我们在“根据应用程序的需求描述模型”中讨论的那样，这里的关键是让我们想要询问的数据问题指导我们引入模型的关系类型。

As we discussed in “Describe the Model in Terms of the Application’s Needs”, the key here is to let the questions we want to ask of our data guide the kinds of relationships we introduce into the model.

将事实模型化为节点

Model Facts as Nodes

当两个或多个领域实体在一段时间内交互时，就会出现一个事实。我们将事实表示为一个单独的节点，该节点与参与该事实的每个实体都有连接。根据其产品（即根据由该操作产生的东西）对操作进行建模会产生类似的结构：一个中间节点，表示两个或多个实体之间交互的结果。我们可以在这个中间节点上使用时间戳属性来表示开始和结束时间。

When two or more domain entities interact for a period of time, a fact emerges. We represent a fact as a separate node with connections to each of the entities engaged in that fact. Modeling an action in terms of its product — that is, in terms of the thing that results from the action — produces a similar structure: an intermediate node that represents the outcome of an interaction between two or more entities. We can use timestamp properties on this intermediate node to represent start and end times.

以下示例展示了如何使用中间节点来建模事实和动作。

The following examples show how we might model facts and actions using intermediate nodes.

就业

Employment

图 4-2显示了 Ian 受雇于 Neo Technology 并担任工程师的事实如何在图中表示出来。

Figure 4-2 shows how the fact of Ian being employed by Neo Technology in the role of engineer can be represented in the graph.

在 Cypher 中，这可以表示为：

In Cypher, this can be expressed as:

CREATE (:Person {name:'Ian'})-[:EMPLOYMENT]->
        (employment:Job {start_date:'2011-01-05'})
        -[:EMPLOYER]->(:Company {name:'Neo'}),
       (employment)-[:ROLE]->(:Role {name:'engineer'})

CREATE (:Person {name:'Ian'})-[:EMPLOYMENT]->
        (employment:Job {start_date:'2011-01-05'})
        -[:EMPLOYER]->(:Company {name:'Neo'}),
       (employment)-[:ROLE]->(:Role {name:'engineer'})

图 4-2。Ian最初在 Neo Technology 担任工程师

表现

Performance

图 4-3显示了威廉·哈特内尔 (William Hartnell) 在故事《The Sensorites》中饰演医生这一事实如何在图表中体现出来。

Figure 4-3 shows how the fact that William Hartnell played The Doctor in the story The Sensorites can be represented in the graph.

在 Cypher 中：

In Cypher:

CREATE (:Actor {name:'William Hartnell'})-[:PERFORMED_IN]->
         (performance:Performance {year:1964})-[:PLAYED]->
         (:Role {name:'The Doctor'}),
       (performance)-[:FOR]->(:Story {title:'The Sensorites'})

CREATE (:Actor {name:'William Hartnell'})-[:PERFORMED_IN]->
         (performance:Performance {year:1964})-[:PLAYED]->
         (:Role {name:'The Doctor'}),
       (performance)-[:FOR]->(:Story {title:'The Sensorites'})

图 4-3。威廉·哈特内尔在故事《感官者》中扮演医生

电子邮件

Emailing

图 4-4显示了 Ian 给 Jim 发送电子邮件并抄送给 Alistair 的行为。

Figure 4-4 shows the act of Ian emailing Jim and copying in Alistair.

图 4-4. Ian 给 Jim 发了一封电子邮件，并抄送给 Alistair

在 Cypher 中，这可以表示为：

In Cypher, this can be expressed as:

CREATE (:Person {name:'Ian'})-[:SENT]->(e:Email {content:'...'})
         -[:TO]->(:Person {name:'Jim'}),
       (e)-[:CC]->(:Person {name:'Alistair'})

CREATE (:Person {name:'Ian'})-[:SENT]->(e:Email {content:'...'})
         -[:TO]->(:Person {name:'Jim'}),
       (e)-[:CC]->(:Person {name:'Alistair'})

审阅

Reviewing

图 4-5显示了 Alistair 评论一部电影的行为如何以图表形式表示。

Figure 4-5 shows how the act of Alistair reviewing a film can be represented in the graph.

在 Cypher 中：

In Cypher:

CREATE (:Person {name:'Alistair'})-[:WROTE]->
         (review:Review {text:'...'})-[:OF]->(:Film {title:'...'}),
       (review)-[:PUBLISHED_IN]->(:Publication {title:'...'})

CREATE (:Person {name:'Alistair'})-[:WROTE]->
         (review:Review {text:'...'})-[:OF]->(:Film {title:'...'}),
       (review)-[:PUBLISHED_IN]->(:Publication {title:'...'})

图 4-5. Alistair 写了一篇电影评论，发表在杂志上

将复杂值类型表示为节点

Represent Complex Value Types as Nodes

值类型是没有身份的事物，其等价性仅基于其值。示例包括money、address和SKU。复杂值类型是具有多个字段或属性的值类型。例如， Address是一种复杂值类型。这种多属性值类型可以有用地表示为单独的节点：

Value types are things that do not have an identity, and whose equivalence is based solely on their values. Examples include money, address, and SKU. Complex value types are value types with more than one field or property. Address, for example, is a complex value type. Such multiproperty value types may be usefully represented as separate nodes:

MATCH (:Order {orderid:13567})-[:DELIVERY_ADDRESS]->(address:Address)
RETURN address.first_line, address.zipcode

MATCH (:Order {orderid:13567})-[:DELIVERY_ADDRESS]->(address:Address)
RETURN address.first_line, address.zipcode

时间

Time

在图表中，时间可以用几种不同的方式建模。这里我们描述了两种技术：时间线树和链接列表。在某些解决方案中，将这两种技术结合起来很有用。

Time can be modeled in several different ways in the graph. Here we describe two techniques: timeline trees and linked lists. In some solutions, it’s useful to combine these two techniques.

时间线树

Timeline trees

如果我们需要找出特定时间段内发生的所有事件，可以构建时间线树，如图4-6所示。

If we need to find all the events that have occurred over a specific period, we can build a timeline tree, as shown in Figure 4-6.

图 4-6.显示电视节目四集播出日期的时间轴树

每年都有自己的一组月份节点；每个月都有自己的一组日期节点。我们只需在需要时将节点插入时间轴树中。假设根节点timeline已被索引，或者可以通过遍历图发现，以下 Cypher 语句可确保特定事件的所有必要节点和关系（年、月、日，以及代表事件本身的节点）已经存在于图中，或者如果不存在，则已添加到图中（MERGE将添加任何缺失的元素）：

Each year has its own set of month nodes; each month has its own set of day nodes. We need only insert nodes into the timeline tree as and when they are needed. Assuming the root timeline node has been indexed, or can be discovered by traversing the graph, the following Cypher statement ensures that all necessary nodes and relationships for a particular event — year, month, day, plus the node representing the event itself — are either already present in the graph, or, if not present, are added to the graph (MERGE will add any missing elements):

MATCH (timeline:Timeline {name:{timelineName}})
MERGE (episode:Episode {name:{newEpisode}})
MERGE (timeline)-[:YEAR]->(year:Year {value:{year}})
MERGE (year)-[:MONTH]->(month:Month {name:{monthName}})
MERGE (month)-[:DAY]->(day:Day {value:{day}, name:{dayName}})
MERGE (day)<-[:BROADCAST_ON]-(episode)

MATCH (timeline:Timeline {name:{timelineName}})
MERGE (episode:Episode {name:{newEpisode}})
MERGE (timeline)-[:YEAR]->(year:Year {value:{year}})
MERGE (year)-[:MONTH]->(month:Month {name:{monthName}})
MERGE (month)-[:DAY]->(day:Day {value:{day}, name:{dayName}})
MERGE (day)<-[:BROADCAST_ON]-(episode)

可以使用以下 Cypher 代码查询日历中开始日期（含）和结束日期（不含）之间的所有事件：

Querying the calendar for all events between a start date (inclusive) and an end date (exclusive) can be done with the following Cypher code:

MATCH (timeline:Timeline {name:{timelineName}})
MATCH (timeline)-[:YEAR]->(year:Year)-[:MONTH]->(month:Month)-[:DAY]->
      (day:Day)<-[:BROADCAST_ON]-(n)
WHERE ((year.value > {startYear} AND year.value < {endYear})
      OR ({startYear} = {endYear} AND {startMonth} = {endMonth}
          AND year.value = {startYear} AND month.value = {startMonth}
          AND day.value >= {startDay} AND day.value < {endDay})
      OR ({startYear} = {endYear} AND {startMonth} < {endMonth}
          AND year.value = {startYear}
          AND ((month.value = {startMonth} AND day.value >= {startDay})
              OR (month.value > {startMonth} AND month.value < {endMonth})
              OR (month.value = {endMonth} AND day.value < {endDay})))
      OR ({startYear} < {endYear}
          AND year.value = {startYear}
          AND ((month.value > {startMonth})
              OR (month.value = {startMonth} AND day.value >= {startDay})))
      OR ({startYear} < {endYear}
          AND year.value = {endYear}
          AND ((month.value < {endMonth})
              OR (month.value = {endMonth} AND day.value < {endDay}))))
RETURN n

MATCH (timeline:Timeline {name:{timelineName}})
MATCH (timeline)-[:YEAR]->(year:Year)-[:MONTH]->(month:Month)-[:DAY]->
      (day:Day)<-[:BROADCAST_ON]-(n)
WHERE ((year.value > {startYear} AND year.value < {endYear})
      OR ({startYear} = {endYear} AND {startMonth} = {endMonth}
          AND year.value = {startYear} AND month.value = {startMonth}
          AND day.value >= {startDay} AND day.value < {endDay})
      OR ({startYear} = {endYear} AND {startMonth} < {endMonth}
          AND year.value = {startYear}
          AND ((month.value = {startMonth} AND day.value >= {startDay})
              OR (month.value > {startMonth} AND month.value < {endMonth})
              OR (month.value = {endMonth} AND day.value < {endDay})))
      OR ({startYear} < {endYear}
          AND year.value = {startYear}
          AND ((month.value > {startMonth})
              OR (month.value = {startMonth} AND day.value >= {startDay})))
      OR ({startYear} < {endYear}
          AND year.value = {endYear}
          AND ((month.value < {endMonth})
              OR (month.value = {endMonth} AND day.value < {endDay}))))
RETURN n

这里的子句WHERE虽然有些冗长，但只是根据查询提供的开始和结束日期过滤每个匹配项。

The WHERE clause here, though somewhat verbose, simply filters each match based on the start and end dates supplied to the query.

链接列表

Linked lists

许多事件与发生在它们之前和之后的事件具有时间关系。我们可以使用NEXT和/或PREVIOUS关系（取决于我们的偏好）来创建捕获这种自然顺序的链接列表，如图4-7所示。2链接^列表允许非常快速地遍历按时间顺序排列的事件。

Many events have temporal relationships to the events that precede and follow them. We can use NEXT and/or PREVIOUS relationships (depending on our preference) to create linked lists that capture this natural ordering, as shown in Figure 4-7.² Linked lists allow for very rapid traversal of time-ordered events.

图 4-7.表示按时间顺序排列的一系列事件的双向链表

迭代和增量开发

Iterative and Incremental Development

我们逐个功能、逐个用户故事开发数据模型。这将确保我们识别应用程序将用于查询图表的关系。根据应用程序功能的迭代和增量交付而开发的数据模型与使用数据模型优先方法制定的数据模型看起来截然不同，但它将是正确的模型，始终受到应用程序需求以及与这些需求相关的问题的驱动。

We develop the data model feature by feature, user story by user story. This will ensure that we identify the relationships our application will use to query the graph. A data model that is developed in line with the iterative and incremental delivery of application features will look quite different from one drawn up using a data model-first approach, but it will be the correct model, motivated throughout by the application’s needs, and the questions that arise in conjunction with those needs.

图形数据库可确保数据模型的平稳演进。迁移和非规范化很少成为问题。新事实和新组合成为新节点和关系，而针对性能关键型访问模式进行优化通常涉及在两个节点之间引入直接关系，否则这两个节点只能通过中介进行连接。与我们在关系世界中采用的优化策略不同，后者通常涉及非规范化，从而损害高保真模型，这不是一个非此即彼的问题：要么是详细的、高度规范化的结构，要么是高性能的妥协。使用图形，我们保留了原始的高保真图形结构，同时用满足新需求的新元素丰富它。

Graph databases provide for the smooth evolution of our data model. Migrations and denormalization are rarely an issue. New facts and new compositions become new nodes and relationships, while optimizing for performance-critical access patterns typically involves introducing a direct relationship between two nodes that would otherwise be connected only by way of intermediaries. Unlike the optimization strategies we employ in the relational world, which typically involve denormalizing and thereby compromising a high-fidelity model, this is not an either/or issue: either the detailed, highly normalized structure, or the high performance compromise. With the graph we retain the original high-fidelity graph structure, while at the same time enriching it with new elements that cater to new needs.

我们将很快看到不同的关系如何并存，满足不同的需求，而不会扭曲模型以偏向任何特定需求。地址有助于说明这一点。例如，假设我们正在开发一个零售应用程序。在开发履行案例时，我们添加了将包裹派送到客户送货地址的功能，我们使用以下查询找到该地址：

We will quickly see how different relationships can sit side-by-side with one another, catering to different needs without distorting the model in favor of any one particular need. Addresses help illustrate the point here. Imagine, for example, that we are developing a retail application. While developing a fulfillment story, we add the ability to dispatch a parcel to a customer’s delivery address, which we find using the following query:

MATCH (user:User {id:{userId}})
MATCH (user)-[:DELIVERY_ADDRESS]->(address:Address)
RETURN address

MATCH (user:User {id:{userId}})
MATCH (user)-[:DELIVERY_ADDRESS]->(address:Address)
RETURN address

稍后，在添加一些计费功能时，我们引入了一种BILLING_ADDRESS关系。稍后，我们又增加了客户管理所有地址的功能。最后一个功能要求我们查找所有地址 — 无论是送货地址、账单地址还是其他地址。为了方便起见，我们引入了一种通用ADDRESS关系：

Later on, when adding some billing functionality, we introduce a BILLING_ADDRESS relationship. Later still, we add the ability for customers to manage all their addresses. This last feature requires us to find all addresses — whether delivery, billing, or some other address. To facilitate this, we introduce a general ADDRESS relationship:

MATCH (user:User {id:{userId}})
MATCH (user)-[:ADDRESS]->(address:Address)
RETURN address

MATCH (user:User {id:{userId}})
MATCH (user)-[:ADDRESS]->(address:Address)
RETURN address

此时，我们的数据模型看起来应该类似于图 4-8中所示的模型。DELIVERY_ADDRESS专门用于代表应用程序的履行需求的数据；BILLING_ADDRESS专门用于代表应用程序的计费需求的数据；并且ADDRESS专门用于代表应用程序的客户管理需求的数据。

By this time, our data model looks something like the one shown in Figure 4-8. DELIVERY_ADDRESS specializes the data on behalf of the application’s fulfillment needs; BILLING_ADDRESS specializes the data on behalf of the application’s billing needs; and ADDRESS specializes the data on behalf of the application’s customer management needs.

图 4-8。不同应用需求的不同关系

仅仅因为我们可以添加新的关系来满足新的应用目标，并不意味着我们总是必须这样做。我们总是会在过程中发现重构模型的机会。例如，有很多次，现有关系足以满足新查询，或者重命名现有关系将允许它用于两种不同的需求。当这些机会出现时，我们应该抓住它们。如果我们以测试驱动的方式开发解决方案（本章后面将更详细地描述），我们将拥有一套完善的回归测试。这些测试让我们有信心对模型进行重大更改。

Just because we can add new relationships to meet new application goals, doesn’t mean we always have to do this. We’ll invariably identify opportunities for refactoring the model as we go. There’ll be plenty of times, for example, where an existing relationship will suffice for a new query, or where renaming an existing relationship will allow it to be used for two different needs. When these opportunities arise, we should take them. If we’re developing our solution in a test-driven manner — described in more detail later in this chapter — we’ll have a sound suite of regression tests in place. These tests give us the confidence to make substantial changes to the model.

嵌入式与服务器

Embedded versus Server

如今，大多数数据库都以服务器的形式运行，可通过客户端库进行访问。Neo4j 有点不同寻常，因为它既可以以嵌入式模式运行，也可以以服务器模式运行 — 事实上，追溯到近十年前，它的起源就是嵌入式图形数据库。

Most databases today run as a server that is accessed through a client library. Neo4j is somewhat unusual in that it can be run in embedded as well as server mode — in fact, going back nearly ten years, its origins are as an embedded graph database.

@Path("/distance")
public class SocialNetworkExtension
{
    private final GraphDatabaseService db;

    public SocialNetworkExtension( @Context GraphDatabaseService db )
    {
        this.db = db;
    }

    @GET
    @Produces("text/plain")
    @Path("/{name1}/{name2}")
    public String getDistance  ( @PathParam("name1") String name1,
                                 @PathParam("name2") String name2 )
    {
        String query = "MATCH (first:User {name:{name1}}),\n" +
                "(second:User {name:{name2}})\n" +
                "MATCH p=shortestPath(first-[*..4]-second)\n" +
                "RETURN length(p) AS depth";

        Map<String, Object> params = new HashMap<String, Object>();
        params.put( "name1", name1 );
        params.put( "name2", name2 );

        Result result = db.execute( query, params );

        return String.valueOf( result.columnAs( "depth" ).next() );
    }
}

@Path("/distance")
public class SocialNetworkExtension
{
    private final GraphDatabaseService db;

    public SocialNetworkExtension( @Context GraphDatabaseService db )
    {
        this.db = db;
    }

    @GET
    @Produces("text/plain")
    @Path("/{name1}/{name2}")
    public String getDistance  ( @PathParam("name1") String name1,
                                 @PathParam("name2") String name2 )
    {
        String query = "MATCH (first:User {name:{name1}}),\n" +
                "(second:User {name:{name2}})\n" +
                "MATCH p=shortestPath(first-[*..4]-second)\n" +
                "RETURN length(p) AS depth";

        Map<String, Object> params = new HashMap<String, Object>();
        params.put( "name1", name1 );
        params.put( "name2", name2 );

        Result result = db.execute( query, params );

        return String.valueOf( result.columnAs( "depth" ).next() );
    }
}

聚类

Clustering

正如我们在“可用性”中更详细地讨论的那样，Neo4j 集群使用主从复制来实现高可用性和水平读取扩展。在本节中，我们将讨论使用集群 Neo4j 时需要考虑的一些策略。

As we discuss in more detail in “Availability”, Neo4j clusters for high availability and horizontal read scaling using master-slave replication. In this section we discuss some of the strategies to consider when using clustered Neo4j.

负载均衡

Load Balancing

使用集群图形数据库时，我们应该考虑在集群中平衡流量负载，以帮助最大化吞吐量并减少延迟。Neo4j 不包含本机负载平衡器，而是依赖于网络基础设施的负载平衡功能。

When using a clustered graph database, we should consider load balancing traffic across the cluster to help maximize throughput and reduce latency. Neo4j doesn’t include a native load balancer, relying instead on the load-balancing capabilities of the network infrastructure.

缓存分片

Cache sharding

当满足查询需求的图部分驻留在主内存中时，查询运行速度最快。当图包含数十亿个节点、关系和属性时，并非所有节点、关系和属性都适合主内存。其他数据技术通常通过对数据进行分区来解决此问题，但对于图，分区或分片异常困难（请参阅“图可扩展性的圣杯”）。那么，我们如何才能在非常大的图上提供高性能查询？

Queries run fastest when the portions of the graph needed to satisfy them reside in main memory. When a graph holds many billions of nodes, relationships, and properties, not all of it will fit into main memory. Other data technologies often solve this problem by partitioning their data, but with graphs, partitioning or sharding is unusually difficult (see “The Holy Grail of Graph Scalability”). How, then, can we provide for high-performance queries over a very large graph?

一种解决方案是使用一种称为缓存分片的技术（图 4-10），该技术包括将每个请求路由到 HA 集群中的数据库实例，其中满足该请求所需的图形部分可能已经在主内存中（请记住：集群中的每个实例都将包含数据的完整副本）。如果应用程序的大多数查询都是图形本地查询，这意味着它们从图形中的一个或多个特定点开始并遍历周围的子图，那么从同一组起点开始的查询一致地路由到同一数据库实例的机制将增加每个查询命中热缓存的可能性。

One solution is to use a technique called cache sharding (Figure 4-10), which consists of routing each request to a database instance in an HA cluster where the portion of the graph necessary to satisfy that request is likely already in main memory (remember: every instance in the cluster will contain a full copy of the data). If the majority of an application’s queries are graph-local queries, meaning they start from one or more specific points in the graph and traverse the surrounding subgraphs, then a mechanism that consistently routes queries beginning from the same set of start points to the same database instance will increase the likelihood of each query hitting a warm cache.

图 4-9。使用读/写负载平衡器将请求定向到群集

实现一致路由的策略因域而异。有时，有粘性会话就足够了；其他时候，我们希望根据数据集的特征进行路由。最简单的策略是让首先为特定用户提供请求的实例，然后为该用户提供后续请求。其他特定于域的方法也有效。例如，在地理数据系统中，我们可以将有关特定位置的请求路由到已为该位置预热的特定数据库实例。这两种策略都增加了所需节点和关系已缓存在主内存中的可能性，在那里可以快速访问和处理它们。

The strategy used to implement consistent routing will vary by domain. Sometimes it’s good enough to have sticky sessions; other times we’ll want to route based on the characteristics of the dataset. The simplest strategy is to have the instance that first serves requests for a particular user thereafter serve subsequent requests for that user. Other domain-specific approaches will also work. For example, in a geographical data system we can route requests about particular locations to specific database instances that have been warmed for that location. Both strategies increase the likelihood of the required nodes and relationships already being cached in main memory, where they can be quickly accessed and processed.

图 4-10.缓存分片

测试驱动的数据模型开发

Test-Driven Data Model Development

在讨论数据建模时，我们强调图形模型应该反映我们想要针对其运行的查询类型。通过以测试驱动的方式开发数据模型，我们可以记录对领域的理解，并验证查询是否正确运行。

In discussing data modeling, we’ve stressed that our graph model should reflect the kinds of queries we want to run against it. By developing our data model in a test-driven fashion we document our understanding of our domain, and validate that our queries behave correctly.

通过测试驱动的数据建模，我们根据从我们的领域中提取的小型代表性示例图编写单元测试。这些示例图包含的数据刚好足以传达领域的特定特征。在许多情况下，它们可能仅包含 10 个左右的节点，以及连接它们的关系。我们使用这些示例来描述领域的正常情况以及异常情况。当我们在真实数据中发现异常和极端情况时，我们会编写一个测试来重现我们发现的情况。

With test-driven data modeling, we write unit tests based on small, representative example graphs drawn from our domain. These example graphs contain just enough data to communicate a particular feature of the domain. In many cases, they might only comprise 10 or so nodes, plus the relationships that connect them. We use these examples to describe what is normal for the domain, and also what is exceptional. As we discover anomalies and corner cases in our real data, we write a test that reproduces what we’ve discovered.

我们为每个测试创建的示例图构成了该测试的设置或上下文。在此上下文中，我们执行查询，并断言查询的行为符合预期。由于我们控制测试数据的内容，因此作为测试的作者，我们知道预期的结果。

The example graphs we create for each test comprise the setup or context for that test. Within this context we exercise a query, and assert that the query behaves as expected. Because we control the contents of the test data, we, as the author of the test, know what results to expect.

测试可以充当文档。通过阅读测试，开发人员可以了解应用程序旨在解决的问题和需求，以及作者解决这些问题的方式。考虑到这一点，最好使用每个测试来测试我们领域的一个方面。阅读大量小型测试要容易得多，每个测试都以清晰、简单和简洁的方式传达我们数据的一个离散特征，而不是通过单个大型且笨拙的测试对复杂领域进行逆向工程。在许多情况下，我们会发现一个特定的查询被几个测试执行，其中一些测试展示了我们领域的顺利路径，另一些测试则在某些特殊结构或值集的上下文中执行它^。5

Tests can act like documentation. By reading the tests, developers gain an understanding of the problems and needs the application is intended to address, and the ways in which the authors have gone about addressing them. With this in mind, it’s best to use each test to test just one aspect of our domain. It’s far easier to read lots of small tests, each of which communicates a discrete feature of our data in a clear, simple, and concise fashion, than it is to reverse engineer a complex domain from a single large and unwieldy test. In many cases, we’ll find a particular query being exercised by several tests, some of which demonstrate the happy path through our domain, others of which exercise it in the context of some exceptional structure or set of values.⁵

随着时间的推移，我们将建立一套可以充当强大回归测试机制的测试。随着应用程序的发展，我们添加新的数据源，或更改模型以满足新的需求，我们的回归测试套件将继续断言现有功能仍然按应有的方式运行。演进架构以及支持它们的增量和迭代软件开发技术依赖于断言行为的基础。此处描述的数据模型开发单元测试方法使开发人员能够响应新的业务需求，而几乎不会破坏或破坏以前的解决方案，并且对解决方案的持续质量充满信心。

Over time, we’ll build up a suite of tests that can act as a powerful regression test mechanism. As our application evolves, and we add new sources of data, or change the model to meet new needs, our regression test suite will continue to assert that existing features still behave as they should. Evolutionary architectures, and the incremental and iterative software development techniques that support them, depend upon a bedrock of asserted behavior. The unit-testing approach to data model development described here enables developers to respond to new business needs with very little risk of undermining or breaking what has come before, confident in the continued quality of the solution.

public GraphDatabaseService createDatabase()
{
    // Create nodes
    String createGraph = "CREATE\n" +
        "(ben:User {name:'Ben'}),\n" +
        "(arnold:User {name:'Arnold'}),\n" +
        "(charlie:User {name:'Charlie'}),\n" +
        "(gordon:User {name:'Gordon'}),\n" +
        "(lucy:User {name:'Lucy'}),\n" +
        "(emily:User {name:'Emily'}),\n" +
        "(sarah:User {name:'Sarah'}),\n" +
        "(kate:User {name:'Kate'}),\n" +
        "(mike:User {name:'Mike'}),\n" +
        "(paula:User {name:'Paula'}),\n" +
        "(ben)-[:FRIEND]->(charlie),\n" +
        "(charlie)-[:FRIEND]->(lucy),\n" +
        "(lucy)-[:FRIEND]->(sarah),\n" +
        "(sarah)-[:FRIEND]->(mike),\n" +
        "(arnold)-[:FRIEND]->(gordon),\n" +
        "(gordon)-[:FRIEND]->(emily),\n" +
        "(emily)-[:FRIEND]->(kate),\n" +
        "(kate)-[:FRIEND]->(paula)";

    String createIndex = "CREATE INDEX ON :User(name)";

    GraphDatabaseService db =
        new TestGraphDatabaseFactory().newImpermanentDatabase();

    db.execute( createGraph );
    db.execute( createIndex );

    return db;
}

public GraphDatabaseService createDatabase()
{
    // Create nodes
    String createGraph = "CREATE\n" +
        "(ben:User {name:'Ben'}),\n" +
        "(arnold:User {name:'Arnold'}),\n" +
        "(charlie:User {name:'Charlie'}),\n" +
        "(gordon:User {name:'Gordon'}),\n" +
        "(lucy:User {name:'Lucy'}),\n" +
        "(emily:User {name:'Emily'}),\n" +
        "(sarah:User {name:'Sarah'}),\n" +
        "(kate:User {name:'Kate'}),\n" +
        "(mike:User {name:'Mike'}),\n" +
        "(paula:User {name:'Paula'}),\n" +
        "(ben)-[:FRIEND]->(charlie),\n" +
        "(charlie)-[:FRIEND]->(lucy),\n" +
        "(lucy)-[:FRIEND]->(sarah),\n" +
        "(sarah)-[:FRIEND]->(mike),\n" +
        "(arnold)-[:FRIEND]->(gordon),\n" +
        "(gordon)-[:FRIEND]->(emily),\n" +
        "(emily)-[:FRIEND]->(kate),\n" +
        "(kate)-[:FRIEND]->(paula)";

    String createIndex = "CREATE INDEX ON :User(name)";

    GraphDatabaseService db =
        new TestGraphDatabaseFactory().newImpermanentDatabase();

    db.execute( createGraph );
    db.execute( createIndex );

    return db;
}

<dependency>
    <groupId>org.neo4j </groupId>
    <artifactId>neo4j-kernel </artifactId>
    <version>${project.version} </version>
    <type>test-jar</type>
    <scope>测试</scope>
</dependency>

<dependency>
    <groupId>org.neo4j</groupId>
    <artifactId>neo4j-kernel</artifactId>
    <version>${project.version}</version>
    <type>test-jar</type>
    <scope>test</scope>
</dependency>

public class SocialNetworkTest
{
    private static GraphDatabaseService db;
    private static SocialNetworkQueries queries;

    @BeforeClass
    public static void init()
    {
        db = createDatabase();
        queries = new SocialNetworkQueries( db );
    }

    @AfterClass
    public static void shutdown()
    {
        db.shutdown();
    }

    @Test
    public void shouldReturnShortestPathBetweenTwoFriends() throws Exception
    {
        // when
        Result result = queries.distance( "Ben", "Mike" );

        // then
        assertTrue( result.hasNext() );
        assertEquals( 4, result.next().get( "distance" ) );
    }

    // more tests
}

public class SocialNetworkTest
{
    private static GraphDatabaseService db;
    private static SocialNetworkQueries queries;

    @BeforeClass
    public static void init()
    {
        db = createDatabase();
        queries = new SocialNetworkQueries( db );
    }

    @AfterClass
    public static void shutdown()
    {
        db.shutdown();
    }

    @Test
    public void shouldReturnShortestPathBetweenTwoFriends() throws Exception
    {
        // when
        Result result = queries.distance( "Ben", "Mike" );

        // then
        assertTrue( result.hasNext() );
        assertEquals( 4, result.next().get( "distance" ) );
    }

    // more tests
}

public class SocialNetworkQueries
{
    private final GraphDatabaseService db;

    public SocialNetworkQueries( GraphDatabaseService db )
    {
        this.db = db;
    }

    public Result distance( String firstUser, String secondUser )
    {
        String query = "MATCH (first:User {name:{firstUser}}),\n" +
            "(second:User {name:{secondUser}})\n" +
            "MATCH p=shortestPath((first)-[*..4]-(second))\n" +
            "RETURN length(p) AS distance";

        Map<String, Object> params = new HashMap<String, Object>();
        params.put( "firstUser", firstUser );
        params.put( "secondUser",  secondUser );

        return db.execute( query, params );
    }

    // More queries
}

public class SocialNetworkQueries
{
    private final GraphDatabaseService db;

    public SocialNetworkQueries( GraphDatabaseService db )
    {
        this.db = db;
    }

    public Result distance( String firstUser, String secondUser )
    {
        String query = "MATCH (first:User {name:{firstUser}}),\n" +
            "(second:User {name:{secondUser}})\n" +
            "MATCH p=shortestPath((first)-[*..4]-(second))\n" +
            "RETURN length(p) AS distance";

        Map<String, Object> params = new HashMap<String, Object>();
        params.put( "firstUser", firstUser );
        params.put( "secondUser",  secondUser );

        return db.execute( query, params );
    }

    // More queries
}

@Test
public void shouldReturnNoResultsWhenNoPathAtDistance4OrLess()
    throws Exception
{
    // when
    Result result = queries.distance( "Ben", "Arnold" );

    // then
    assertFalse( result.hasNext() );
}

@Test
public void shouldReturnNoResultsWhenNoPathAtDistance4OrLess()
    throws Exception
{
    // when
    Result result = queries.distance( "Ben", "Arnold" );

    // then
    assertFalse( result.hasNext() );
}

@Test
public void extensionShouldReturnDistance() throws Exception
{
    // given
    SocialNetworkExtension extension = new SocialNetworkExtension( db );

    // when
    String distance = extension.getDistance( "Ben", "Mike" );

    // then
    assertEquals( "4", distance );
}

@Test
public void extensionShouldReturnDistance() throws Exception
{
    // given
    SocialNetworkExtension extension = new SocialNetworkExtension( db );

    // when
    String distance = extension.getDistance( "Ben", "Mike" );

    // then
    assertEquals( "4", distance );
}

public class SocialNetworkExtensionTest
{
    private ServerControls server;

    @BeforeClass
    public static void init() throws IOException
    {
        // Create nodes
        String createGraph = "CREATE\n" +
            "(ben:User {name:'Ben'}),\n" +
            "(arnold:User {name:'Arnold'}),\n" +
            "(charlie:User {name:'Charlie'}),\n" +
            "(gordon:User {name:'Gordon'}),\n" +
            "(lucy:User {name:'Lucy'}),\n" +
            "(emily:User {name:'Emily'}),\n" +
            "(sarah:User {name:'Sarah'}),\n" +
            "(kate:User {name:'Kate'}),\n" +
            "(mike:User {name:'Mike'}),\n" +
            "(paula:User {name:'Paula'}),\n" +
            "(ben)-[:FRIEND]->(charlie),\n" +
            "(charlie)-[:FRIEND]->(lucy),\n" +
            "(lucy)-[:FRIEND]->(sarah),\n" +
            "(sarah)-[:FRIEND]->(mike),\n" +
            "(arnold)-[:FRIEND]->(gordon),\n" +
            "(gordon)-[:FRIEND]->(emily),\n" +
            "(emily)-[:FRIEND]->(kate),\n" +
            "(kate)-[:FRIEND]->(paula)";

        server = TestServerBuilders
            .newInProcessBuilder()
            .withExtension(
                "/socnet",
                ColleagueFinderExtension.class )
            .withFixture( createGraph )
            .newServer();
    }

    @AfterClass
    public static void teardown()
    {
        server.close();
    }

    @Test
    public void serverShouldReturnDistance() throws Exception
    {
        HTTP.Response response = HTTP.GET( server.httpURI()
            .resolve( "/socnet/distance/Ben/Mike" ).toString() );

        assertEquals( 200, response.status() );
        assertEquals( "text/plain", response.header( "Content-Type" ));
        assertEquals( "4", response.rawContent( ) );
    }
}

public class SocialNetworkExtensionTest
{
    private ServerControls server;

    @BeforeClass
    public static void init() throws IOException
    {
        // Create nodes
        String createGraph = "CREATE\n" +
            "(ben:User {name:'Ben'}),\n" +
            "(arnold:User {name:'Arnold'}),\n" +
            "(charlie:User {name:'Charlie'}),\n" +
            "(gordon:User {name:'Gordon'}),\n" +
            "(lucy:User {name:'Lucy'}),\n" +
            "(emily:User {name:'Emily'}),\n" +
            "(sarah:User {name:'Sarah'}),\n" +
            "(kate:User {name:'Kate'}),\n" +
            "(mike:User {name:'Mike'}),\n" +
            "(paula:User {name:'Paula'}),\n" +
            "(ben)-[:FRIEND]->(charlie),\n" +
            "(charlie)-[:FRIEND]->(lucy),\n" +
            "(lucy)-[:FRIEND]->(sarah),\n" +
            "(sarah)-[:FRIEND]->(mike),\n" +
            "(arnold)-[:FRIEND]->(gordon),\n" +
            "(gordon)-[:FRIEND]->(emily),\n" +
            "(emily)-[:FRIEND]->(kate),\n" +
            "(kate)-[:FRIEND]->(paula)";

        server = TestServerBuilders
            .newInProcessBuilder()
            .withExtension(
                "/socnet",
                ColleagueFinderExtension.class )
            .withFixture( createGraph )
            .newServer();
    }

    @AfterClass
    public static void teardown()
    {
        server.close();
    }

    @Test
    public void serverShouldReturnDistance() throws Exception
    {
        HTTP.Response response = HTTP.GET( server.httpURI()
            .resolve( "/socnet/distance/Ben/Mike" ).toString() );

        assertEquals( 200, response.status() );
        assertEquals( "text/plain", response.header( "Content-Type" ));
        assertEquals( "4", response.rawContent( ) );
    }
}

性能测试

Performance Testing

到目前为止，我们描述的测试驱动方法传达了上下文和领域理解，并测试了正确性。但是，它不测试性能。对小型 20 节点样本图有效的方法在面对更大的图时可能效果不佳。因此，为了配合我们的单元测试，我们应该考虑编写一套查询性能测试。除此之外，我们还应该在应用程序开发生命周期的早期投资进行一些彻底的应用程序性能测试。

The test-driven approach that we’ve described so far communicates context and domain understanding, and tests for correctness. It does not, however, test for performance. What works fast against a small, 20-node sample graph may not work so well when confronted with a much larger graph. Therefore, to accompany our unit tests, we should consider writing a suite of query performance tests. On top of that, we should also invest in some thorough application performance testing early in our application’s development life cycle.

private void createSampleDataset( GraphDatabaseService db )
{
    DatasetManager dsm = new DatasetManager( db, SysOutLog.INSTANCE );

    // User node specification
    NodeSpecification userSpec =
        dsm.nodeSpecification( "User",
            indexableProperty( db, "User", "name" ) );

    // FRIEND relationship specification
    RelationshipSpecification friend =
        dsm.relationshipSpecification( "FRIEND" );

    Dataset dataset =
        dsm.newDataset( "Social network example" );

    // Create user nodes
    NodeCollection users =
        userSpec.create( 1_000_000 ).update( dataset );


    // Relate users to each other
    users.createRelationshipsTo(
        getExisting( users )
            .numberOfTargetNodes( minMax( 50, 100 ) )
            .relationship( friend )
            .relationshipConstraints( RelationshipUniqueness.BOTH_DIRECTIONS ) )
        .updateNoReturn( dataset );

    dataset.end();
}

private void createSampleDataset( GraphDatabaseService db )
{
    DatasetManager dsm = new DatasetManager( db, SysOutLog.INSTANCE );

    // User node specification
    NodeSpecification userSpec =
        dsm.nodeSpecification( "User",
            indexableProperty( db, "User", "name" ) );

    // FRIEND relationship specification
    RelationshipSpecification friend =
        dsm.relationshipSpecification( "FRIEND" );

    Dataset dataset =
        dsm.newDataset( "Social network example" );

    // Create user nodes
    NodeCollection users =
        userSpec.create( 1_000_000 ).update( dataset );


    // Relate users to each other
    users.createRelationshipsTo(
        getExisting( users )
            .numberOfTargetNodes( minMax( 50, 100 ) )
            .relationship( friend )
            .relationshipConstraints( RelationshipUniqueness.BOTH_DIRECTIONS ) )
        .updateNoReturn( dataset );

    dataset.end();
}

优化标准

Optimization Criteria

在规划生产环境时，我们将面临许多优化选择。我们青睐哪种选择取决于我们的业务需求：

As we plan our production environment we will be faced with a number of optimization choices. Which we favor will depend upon our business needs:

我们可以通过安装完成工作所需的最少硬件来优化成本。

We can optimize for cost by installing the minimum hardware necessary to get the job done.

我们可以通过采购最快的解决方案来优化性能（受预算限制）。

We can optimize for performance by procuring the fastest solution (subject to budgetary constraints).

我们可以通过确保数据库集群足够大以承受一定数量的机器故障（即，为了承受两台机器故障，我们需要一个由五个实例组成的集群）来优化冗余和可用性。

We can optimize for redundancy and availability by ensuring the database cluster is big enough to survive a certain number of machine failures (i.e., to survive two machines failing, we will need a cluster comprising five instances).

和复制图形数据库解决方案，我们可以通过水平扩展（对于读取负载）和垂直扩展（对于写入负载）来优化负载。

With a replicated graph database solution, we can optimize for load by scaling horizontally (for read load) and vertically (for write load).

表现

Performance

冗余和负载可以根据确保可用性所需的机器数量（例如，在两台机器发生故障的情况下，需要五台机器来提供持续可用性）和可扩展性（每处理一定数量的并发请求需要一台机器，如“负载”中的计算）来计算成本。但性能呢？我们如何计算性能成本？

Redundancy and load can be costed in terms of the number of machines necessary to ensure availability (five machines to provide continued availability in the face of two machines failing, for example) and scalability (one machine per some number of concurrent requests, as per the calculations in “Load”). But what about performance? How can we cost performance?

性能优化选项

Performance optimization options

那么，我们可以从三个方面进行性能优化：

There are, then, three areas in which we can optimize for performance:

• 增加 JVM 堆大小。
• Increase the JVM heap size.
• 增加映射到页面缓存的存储百分比。
• Increase the percentage of the store mapped into the page caches.
• 投资更快的磁盘：SSD 或企业闪存硬件。
• Invest in faster disks: SSDs or enterprise flash hardware.

如图4-11所示，成本与性能权衡的最佳点在于，我们可以将存储文件全部映射到页面缓存中，同时允许使用健康但大小适中的堆。4 到 8 GB 之间的堆并不罕见，但在许多情况下，较小的堆实际上可以提高性能（通过减轻昂贵的 GC 行为）。

As Figure 4-11 shows, the sweet spot for any cost versus performance trade-off lies around the point where we can map our store files in their entirety into the page cache, while allowing for a healthy, but modestly sized heap. Heaps of between 4 and 8 GB are not uncommon, though in many cases, a smaller heap can actually improve performance (by mitigating expensive GC behaviors).

计算要分配给堆和页面缓存的 RAM 量取决于我们对图的预计大小的了解。在应用程序开发生命周期的早期构建一个代表性数据集将为我们提供进行计算所需的一些数据。如果我们无法将整个图放入主内存中，则应考虑缓存分片（请参阅“缓存分片”）。

Calculating how much RAM to allocate to the heap and the page cache depends on our knowing the projected size of our graph. Building a representative dataset early in our application’s development life cycle will furnish us with some of the data we need to make our calculations. If we cannot fit the entire graph into main memory, we should consider cache sharding (see “Cache sharding”).

---

笔记

有关更多常规性能和调整技巧，请参阅此站点。

For more general performance and tuning tips, see this site.

---

图 4-11.成本与性能的权衡

在优化图形数据库解决方案的性能时，我们应该牢记以下准则：

In optimizing a graph database solution for performance, we should bear in mind the following guidelines:

• 我们应该尽可能地利用页面缓存；如果可能的话，我们应该将我们的存储文件全部映射到这个缓存中。
• We should utilize the page cache as much as possible; if possible, we should map our store files in their entirety into this cache.
• 我们应该在监控垃圾收集的同时调整 JVM 堆以确保行为顺畅。
• We should tune the JVM heap while monitoring garbage collection to ensure smooth behavior.
• 当磁盘访问不可避免时，我们应该考虑使用快速磁盘（SSD 或企业闪存硬件）来提高基线性能。
• We should consider using fast disks — SSDs or enterprise flash hardware — to boost baseline performance when disk access becomes inevitable.

冗余

Redundancy

规划冗余需要我们确定在保持应用程序正常运行的情况下，我们可以承受集群中丢失多少个实例。对于非业务关键型应用程序，这个数字可能低至 1（甚至为 0）。一旦第一个实例发生故障，另一个故障将导致应用程序不可用。业务关键型应用程序可能需要至少两个冗余；也就是说，即使两台机器发生故障，应用程序仍会继续处理请求。

Planning for redundancy requires us to determine how many instances in a cluster we can afford to lose while keeping the application up and running. For non–business-critical applications, this figure might be as low as one (or even zero). Once a first instance has failed, another failure will render the application unavailable. Business-critical applications will likely require redundancy of at least two; that is, even after two machines have failed, the application continues serving requests.

对于集群管理协议要求大多数成员可用才能正常工作的图形数据库，使用三或四个实例即可实现 1 的冗余，使用五个实例即可实现 2 的冗余。在这方面，四个并不比三个好，因为如果四实例集群中的两个实例不可用，其余的协调器将不再能够实现多数。

For a graph database whose cluster management protocol requires a majority of members to be available to work properly, redundancy of one can be achieved with three or four instances, and redundancy of two with five instances. Four is no better than three in this respect, because if two instances from a four-instance cluster become unavailable, the remaining coordinators will no longer be able to achieve majority.

加载

Load

优化负载可能是容量规划中最棘手的部分。经验法则如下：

Optimizing for load is perhaps the trickiest part of capacity planning. As a rule of thumb:

并发请求数 = (1000 / 平均请求时间（毫秒）) * 每台机器的核心数 * 机器数量

number of concurrent requests = (1000 / average request time (in milliseconds)) * number of cores per machine * number of machines

实际上确定这些数字是多少或预计是多少有时会非常困难：

Actually determining what some of these figures are, or are projected to be, can sometimes be very difficult:

这涵盖了从服务器收到请求到发送响应的时间段。性能测试可以帮助确定平均请求时间，假设测试是在代表性硬件上运行的，并且针对代表性数据集（如果不是，我们将不得不相应地进行对冲）。在许多情况下，“代表性数据集”本身是基于粗略估计的；每当这个估计发生变化时，我们都应该修改我们的数字。

This covers the period from when a server receives a request, to when it sends a response. Performance tests can help determine average request time, assuming the tests are running on representative hardware against a representative dataset (we’ll have to hedge accordingly if not). In many cases, the “representative dataset” itself is based on a rough estimate; we should modify our figures whenever this estimate changes.

我们应该在这里区分平均负载和峰值负载。确定新应用程序必须支持的并发请求数是一件困难的事情。如果我们要替换或升级现有应用程序，我们可能会访问一些最近的生产统计数据，我们可以使用这些数据来改进我们的估算。一些组织能够从现有应用程序数据中推断出新应用程序的可能要求。除此之外，由我们的利益相关者来估计系统的预计负载，但我们必须注意过高的期望。

We should distinguish here between average load and peak load. Determining the number of concurrent requests a new application must support is a difficult thing to do. If we’re replacing or upgrading an existing application, we may have access to some recent production statistics we can use to refine our estimates. Some organizations are able to extrapolate from existing application data the likely requirements for a new application. Other than that, it’s up to our stakeholders to estimate the projected load on the system, but we must beware of inflated expectations.

初始导入

Initial Import

对于初始导入，Neo4j 有一个名为的初始加载工具neo4j-import，该工具可实现每秒约 1,000,000 条记录的持续摄取速度。8^它之所以能实现这些令人印象深刻的性能数字，是因为它不使用数据库的常规事务功能来构建存储文件。相反，它以类似栅格的方式构建存储文件，添加各个图层直到存储完成，并且只有在完成时，存储才会变得一致。

For initial imports Neo4j has an initial load tool called neo4j-import, which achieves sustained ingest speeds of around 1,000,000 records per second.⁸ It achieves these impressive performance figures because it does not build the store files using the normal transactional capabilities of the database. Instead, it builds the store files in a raster-like fashion, adding individual layers until the store is complete, and it is only at completion that the store becomes consistent.

该工具的输入neo4j-import是一组提供节点和关系数据的 CSV 文件。例如，请考虑以下三个 CSV 文件，它们代表一个小的电影数据集。

The input to the neo4j-import tool is a set of CSV files that provide node and relationship data. As an example, consider the following three CSV files, which represent a small movie data set.

第一个文件是movies.csv：

The first file is movies.csv:

:ID,标题,年份:int,:LABEL
1、《黑客帝国》，1999年，电影
2、《黑客帝国2：重装上阵》2003年电影；续集
3、《黑客帝国3：矩阵革命》2003年电影续集

:ID,title,year:int,:LABEL
1,"The Matrix",1999,Movie
2,"The Matrix Reloaded",2003,Movie;Sequel
3,"The Matrix Revolutions",2003,Movie;Sequel

第一个文件代表电影本身。文件的第一行包含描述电影的元数据。在本例中，我们可以看到每部电影都有一个ID、一个title和year（一个整数）。该ID字段充当键。导入的其他部分可以使用其来引用电影ID。电影还有一个或多个标签：Movie和Sequel。

This first file represents the movies themselves. The first line of the file contains metadata describing the movies. In this case, we can see that each movie has an ID, a title, and a year (which is an integer). The ID field acts as a key. Other parts of the import can refer to a movie using its ID. Movies also have one or more labels: Movie and Sequel.

第二个文件actors.csv包含电影演员。我们可以看到，actors 有一个IDandname属性和一个Actor标签：

The second file, actors.csv, contains movie actors. As we can see, actors have an ID and name property, and an Actor label:

:ID,名称,:标签
基努，“基努·里维斯”，演员
laurence，“劳伦斯·菲什伯恩”，演员
carrieanne，“凯莉-安·莫斯”，演员

:ID,name,:LABEL
keanu,"Keanu Reeves",Actor
laurence,"Laurence Fishburne",Actor
carrieanne,"Carrie-Anne Moss",Actor

第三个文件roles.csv指定了演员在电影中扮演的角色。此文件用于创建图中的关系：

The third file, roles.csv, specifies the roles that actors played in the movies. This file is used to create the relationships in the graph:

:START_ID,角色,:END_ID,:类型
基努，“Neo”，1，ACTS_IN
基努，“Neo”，2，ACTS_IN
基努，“Neo”，3，ACTS_IN
劳伦斯，“莫菲斯”，1，ACTS_IN
劳伦斯，“莫菲斯”，2，ACTS_IN
劳伦斯，“莫菲斯”，3，ACTS_IN
carrieanne,"三位一体",1,ACTS_IN
carrieanne，“三位一体”，2，ACTS_IN
carrieanne，“三位一体”，3，ACTS_IN

:START_ID,role,:END_ID,:TYPE
keanu,"Neo",1,ACTS_IN
keanu,"Neo",2,ACTS_IN
keanu,"Neo",3,ACTS_IN
laurence,"Morpheus",1,ACTS_IN
laurence,"Morpheus",2,ACTS_IN
laurence,"Morpheus",3,ACTS_IN
carrieanne,"Trinity",1,ACTS_IN
carrieanne,"Trinity",2,ACTS_IN
carrieanne,"Trinity",3,ACTS_IN

此文件中的每一行都包含一个START_ID和一个END_ID、一个role值和一个关系TYPE。START_ID值包括ID来自演员 CSV 文件中的演员值。END_ID值包括ID来自电影 CSV 文件中的电影值。每个关系都表示为一个START_ID和一个END_ID，具有一个role属性和一个从关系派生的名称TYPE。

Each line in this file contains a START_ID and an END_ID, a role value and a relationship TYPE. START_ID values comprise actor ID values from the actors CSV file. END_ID values comprise movie ID values from the movies CSV file. Each relationship is expressed as a START_ID and an END_ID, with a role property, and a name derived from the relationship TYPE.

有了这些文件，我们可以从命令行运行导入工具：

With these files, we can run the import tool from the command line:

neo4j-导入--进入目标目录\
--节点电影.csv --节点演员.csv --关系角色.csv

neo4j-import --into target_directory \
--nodes movies.csv --nodes actors.csv --relationships roles.csv

neo4j-import构建数据库存储文件，并将其放入target_directory。

neo4j-import builds the database store files, and puts them in the target_directory.

批量导入

Batch Import

另一个常见要求是将来自外部系统的批量数据推送到实时图表中。在 Neo4j 中，这通常使用 Cypher 的LOAD CSV命令来执行。LOAD CSV以与我们在该工具中使用的相同类型的 CSV 数据作为输入neo4j-import。它旨在支持大约一百万个项目的中间负载，使其成为处理来自上游系统的定期批量更新的理想选择。

Another common requirement is to push bulk data from external systems into a live graph. In Neo4j this is commonly performed using Cypher’s LOAD CSV command. LOAD CSV takes as input the same kind of CSV data we used with the neo4j-import tool. It is designed to support intermediate loads of around a million or so items, making it ideal for handling regular batch updates from upstream systems.

举个例子，让我们用一些关于设定位置的数据来丰富我们现有的电影图表。locations.csv包含和字段，其中是用分号分隔的电影拍摄地点列表：titlelocationlocation

As an example, let’s enrich our existing movie graph with some data about set locations. locations.csv contains title and location fields, where location is a semi-colon-separated list of filming locations in the movie:

标题，地点
《黑客帝国》，悉尼
《黑客帝国2：重装上阵》，悉尼；奥克兰
《黑客帝国3》，悉尼；奥克兰；阿拉米达

title,locations
"The Matrix",Sydney
"The Matrix Reloaded",Sydney;Oakland
"The Matrix Revolutions",Sydney;Oakland;Alameda

有了这些数据，我们可以使用 Cypher 命令将其加载到实时 Neo4j 数据库中，LOAD CSV如下所示：

Given this data, we can load it into a live Neo4j database using the Cypher LOAD CSV command as follows:

LOAD CSV WITH HEADERS FROM 'file:///data/locations.csv' AS line
WITH split(line.locations,";") as locations, line.title as title
UNWIND locations AS location
MERGE (x:Location {name:location})
MERGE (m:Movie {title:title})
MERGE (m)-[:FILMED_IN]->(x)

LOAD CSV WITH HEADERS FROM 'file:///data/locations.csv' AS line
WITH split(line.locations,";") as locations, line.title as title
UNWIND locations AS location
MERGE (x:Location {name:location})
MERGE (m:Movie {title:title})
MERGE (m)-[:FILMED_IN]->(x)

这个 Cypher 脚本的第一行告诉数据库我们想要从文件 URI（LOAD CSV也适用于 HTTP URI）加载一些 CSV 数据。WITH HEADERS告诉数据库我们的 CSV 文件的第一行包含命名标题。AS line将输入文件分配给变量line。然后，将针对源文件中的每一行 CSV 数据执行脚本的其余部分。

The first line of this Cypher script tells the database that we want to load some CSV data from a file URI (LOAD CSV also works with HTTP URIs). WITH HEADERS tells the database that the first line of our CSV file contains named headers. AS line assigns the input file to the variable line. The rest of the script will then be executed for each line of CSV data in the source file.

脚本的第二行以 开头WITH，使用 Cypher 函数将单个行的locations值拆分为字符串集合split。然后，它将生成的集合和行的title值传递给脚本的其余部分。

The second line of the script, beginning with WITH, splits an individual line’s locations value into a collection of strings using Cypher’s split function. It then passes the resulting collection and the line’s title value on to the rest of the script.

UNWIND有趣的工作就从这里开始了。UNWIND扩展一个集合。在这里，我们用它将locations集合扩展为单独的行（请记住，此时我们正在处理单个电影的拍摄地点），后面的语句location将处理每一行。MERGE

UNWIND is where the interesting work begins. UNWIND expands a collection. Here, we use it to expand the locations collection into individual location rows (remember, we’re dealing at this point with a single movie’s locations), each of which will be processed by the MERGE statements that follow.

第一条MERGE语句确保位置由数据库中的节点表示。第二条MERGE语句确保电影也作为节点存在。第三条MERGE语句确保FILMED_IN位置和电影节点之间存在关系。

The first MERGE statement ensures that the location is represented by a node in the database. The second MERGE statement ensures that the movie is also present as a node. The third MERGE statement ensures that a FILMED_IN relationship exists between the location and movie nodes.

MERGE (:Movie {title:title})-[:FILMED_IN]->
      (:Location {name:location}))

MERGE (:Movie {title:title})-[:FILMED_IN]->
      (:Location {name:location}))

此时，我们能够将批量 CSV 数据插入实时图表。但是，我们尚未考虑导入的机械影响。如果我们要在现有的大型数据集上运行这样的大型查询，则插入可能会花费很长时间。为了提高导入效率，我们需要考虑导入的两个关键特征：

At this point we are able to insert bulk CSV data into a live graph. However, we have not yet considered the mechanical implications of our import. In we were to run large queries like this on an existing large dataset, it is likely that the insert would take a very long time. There are two key characteristics of import we need to consider in order to make it efficient:

• 对现有图表进行索引
• Indexing of the existing graph
• 通过数据库的事务流
• Transaction flow through the database

对于我们这些有关系背景的人来说，索引的必要性（可能）在这里是显而易见的。如果没有索引，我们必须搜索数据库中的所有电影节点（最坏的情况下是所有节点）才能确定电影是否存在。这是一个成本为O(n) 的操作。有了电影索引，这个成本就降到了O(log n)，这是一个实质性的改进，尤其是对于较大的数据集而言。位置也是如此。

For those of us coming from a relational background, the need for indexing is (perhaps) obvious here. Without indexes, we have to search all movie nodes in the database (and in the worst case, all of the nodes) in order to determine whether a movie exists or not. This is a cost O(n) operation. With an index of movies, that cost drops to O(log n), which is a substantial improvement, especially for larger data sets. The same is true of locations.

正如我们在上一章中看到的，声明索引很简单。要索引电影，我们只需发出命令CREATE INDEX ON :Movie(title)。我们可以通过浏览器或使用 shell 来执行此操作。如果索引仅在导入期间有用（即它在操作查询中不起作用），那么我们在导入后使用 将其删除DROP INDEX ON :Movie(title)。

Declaring an index, as we saw in the previous chapter, is straightforward. To index movies, we simply issue the command CREATE INDEX ON :Movie(title). We can do this via the browser or using the shell. If the index is useful only during import (i.e., it plays no role in operational queries) then we drop it after the import with DROP INDEX ON :Movie(title).

鉴于对实时 Neo4j 实例的更新是事务性的，因此批量导入LOAD CSV也是事务性的。在最简单的情况下，LOAD CSV构建一个事务并将其提供给数据库。对于较大的批量插入，这在机械上可能非常低效，因为数据库必须管理大量事务状态（有时是 GB）。

Given that updates to live Neo4j instances are transactional, it follows that batch imports with LOAD CSV are also transactional. In the simplest case, LOAD CSV builds one transaction and feeds it to the database. For larger batch insertions this can be quite inefficient mechanically because the database has to manage a large amount of transaction state (sometimes gigabytes).

对于大量数据导入，我们可以通过将单个大型事务提交分解为一系列较小的提交来提高性能，然后对数据库按顺序执行这些提交。为了实现这一点，我们使用功能PERIODIC COMMIT。PERIODIC COMMIT将导入分解为一组较小的事务，这些事务在处理了一定数量的行（默认为 1000 行）后提交。对于我们的电影位置数据，我们可以选择将每个事务的默认 CSV 行数减少到 100 行，例如，通过在 Cypher 脚本前面添加USING PERIODIC COMMIT 100。完整脚本为：

For large data imports, we can boost performance by breaking down a single large transactional commit into a series of smaller commits, which are then executed serially against the database. To achieve this, we use the PERIODIC COMMIT functionality. PERIODIC COMMIT breaks the import into a set of smaller transactions, which are committed after a certain number of rows (1000 by default) have been processed. With our movie location data, we could choose to reduce the default number of CSV lines per transaction to 100, for example, by prepending the Cypher script with USING PERIODIC COMMIT 100. The full script is:

USING PERIODIC COMMIT 100
LOAD CSV WITH HEADERS FROM 'file:///data/locations.csv' AS line
WITH split(line.locations,";") as locations, line.title as title
UNWIND locations AS location
MERGE (x:Location {name:location})
MERGE (m:Movie {title:title})
MERGE (m)-[:FILMED_IN]->(x)

USING PERIODIC COMMIT 100
LOAD CSV WITH HEADERS FROM 'file:///data/locations.csv' AS line
WITH split(line.locations,";") as locations, line.title as title
UNWIND locations AS location
MERGE (x:Location {name:location})
MERGE (m:Movie {title:title})
MERGE (m)-[:FILMED_IN]->(x)

这些用于加载批量数据的功能使我们既可以在设计系统时试验示例数据集，也可以在生产部署中与其他系统和数据源集成。CSV 是一种普遍的数据交换格式——几乎每种数据和集成技术都支持生成 CSV 输出。这使得将数据导入 Neo4j 变得非常容易，无论是作为一次性活动还是定期基础。

These facilities for loading bulk data allow us both to experiment with example datasets when designing a system, and integrate with other systems and sources of data as part of a production deployment. CSV is an ubiquitous data exchange format — almost every data and integration technology has some support for producing CSV output. This makes it extrememly easy to import data into Neo4j, either as a one-time activity or on a periodic basis.